|
EF is designed for application first dbs which are universally garbage and on top of that it has this stupid loving entity layer thing that makes using it a pain in the dick
|
#
?
Oct 27, 2017 02:10
|
|
|
|
| # ? Jun 8, 2024 18:26 |
|
|
yeah ef admittedly expects a ton of control over your db, even by orm standards. it's such a bad fit for existing dbs.
|
|
#
?
Oct 27, 2017 02:13
|
|
|
eschaton posted:please make a smiley out of this these are all over the file size limit, but the dimensions are within limits. these are really good, imo and definitely should be added.   
|
|
#
?
Oct 27, 2017 10:15
|
|
|
now that kinect is discontinued (and already getting really hard to buy in switzerland where i live), is there any alternative combination of hardware + software to do full-body skeleton tracking? preferably something i can code in .NET, NodeJS, or some other "get poo poo done quickly" language? honestly i am not looking for code reuse and a nice architecture. this is more of an artistic project
|
|
#
?
Oct 27, 2017 11:27
|
|
|
go play outside Skyler posted:now that kinect is discontinued (and already getting really hard to buy in switzerland where i live), is there any alternative combination of hardware + software to do full-body skeleton tracking? not really, no. apple bought the company who made the chipset that powered the kinect. i actually worked on a medical project that used the kinect to do 3d scans a little bit before apple bought them. the company eventually had to email tim cook and he got them to send a bunch of kinect stock.
|
|
#
?
Oct 27, 2017 14:12
|
|
|
CRIP EATIN BREAD posted:not really, no. apple bought the company who made the chipset that powered the kinect. damnit timb!
|
|
#
?
Oct 27, 2017 14:54
|
|
|
CRIP EATIN BREAD posted:not really, no. apple bought the company who made the chipset that powered the kinect. lol apple is literally the new microsoft
|
|
#
?
Oct 27, 2017 16:09
|
|
|
is there a link to this message queue post by tef? i’m interested
|
|
#
?
Oct 27, 2017 16:21
|
|
|
Sapozhnik posted:lol apple is literally the new microsoft Steve Ballmer > Tim Cook
|
|
#
?
Oct 27, 2017 16:25
|
|
|
oh no blimp issue posted:is there a link to this message queue post by tef? i’m interested they are somewhere in the old thread. the problems people get themselves into with queues are 1. using a queue to solve overloading ( monococqc with the pictures blog https://ferd.ca/queues-don-t-fix-overload.html ) 2. using a queue as a (global) message bus to decouple services if you search around there are a nontrivial number of talks about how companies took their MESSY FAILING service to service model and switched to a bunch of spokes shoving untrackable poo poo into kafka
|
|
#
?
Oct 27, 2017 16:31
|
|
|
Fiedler posted:Steve Ballmer > Tim Cook apple is 90s microsoft except unlike 90s microsoft it has pathetic sycophants even in the 219 constantly slurping the dick of this trillion dollar corporation "here's to the misfits!" :iamafag:
|
|
#
?
Oct 27, 2017 16:36
|
|
|
oh no blimp issue posted:is there a link to this message queue post by tef? i’m interested https://programmingisterrible.com/post/162346490883/how-do-you-cut-a-monolith-in-half
|
|
#
?
Oct 27, 2017 16:37
|
|
|
Shaggar posted:ef is so bad Yeah, I'll agree with you here. A million ways to do the same thing, and all of them are bad.
|
|
#
?
Oct 27, 2017 16:47
|
|
|
thanks my dude
|
|
#
?
Oct 27, 2017 16:47
|
|
|
i'm about to start writing a jnr-ffi binding for cuda yeah, jcuda is a thing, but supposedly (supposedly) jnr-ffi can achieve better perf than plain jni, while also being easier to write and being what project panama is based off. plus, jcuda only supports cuda 8, and I'd like to write something that supports cuda 9 (even tho i don't use anything specifically in cuda 9). finally, i should be able to have a library that doesn't require -linux-x86_64.jar if i do this. gonna start with NVRTC since it seems simple enough...
|
|
#
?
Oct 27, 2017 17:38
|
|
|
go play outside Skyler posted:now that kinect is discontinued (and already getting really hard to buy in switzerland where i live), is there any alternative combination of hardware + software to do full-body skeleton tracking? CRIP EATIN BREAD posted:not really, no. apple bought the company who made the chipset that powered the kinect. yeah as i understand it apple basically bought PrimeSense to lock down the concept of "3D depth camera via IR speckle pattern projection" and isn't making a standalone unit to replace all the other sensors that no longer have access to the required components. looks like the tech ended up as iphone x face ID. the asus xtion does basically the same thing as the kinect and has good open-source drivers through OpenNI2 but it's got the same component supply problem as the kinect so the ones still on the market are getting more and more expensive as robotics labs hoard them to support ongoing projects. the asus xtion 2 is a laser time-of-flight sensor (to dodge the IP issues, i guess). in theory it also works with OpenNI2 but the driver isn't well documented and i don't know anyone who's actually gotten it working independently from its bundled software. here's a list of other depth cameras (as of December 2016). lots of them show up as out-of-stock today. i've worked with these kinds of sensors through ROS (generally using C++, though Python's an option too). i haven't done skeleton tracking but there's at least one ROS package that looks like it can do it. i won't claim that it's really a "get poo poo done quickly"-type arrangement but it's pretty easy to graft on additional functionality once you know what's up. ROS packages for depth cameras generally use OpenNI2, so that's an option if you want to work standalone.
|
|
#
?
Oct 27, 2017 18:32
|
|
|
Glorgnole posted:yeah as i understand it apple basically bought PrimeSense to lock down the concept of "3D depth camera via IR speckle pattern projection" and isn't making a standalone unit to replace all the other sensors that no longer have access to the required components. looks like the tech ended up as iphone x face ID. OpenNI2 is really bad because it uses a ton of threads for no reason and bitbangs poo poo over libusb, so I ended up writing a linux kernel driver so that it could stream the data as fast as it was being captured. There was another guy who wrote kernel driver that exposes everything using Video4Linux APIs, but we really needed the raw data and didn't care about getting it in whatever N-bit depth image he was exposing it as. Plus using ioctl to control the camera wasn't all that appealing.
|
|
#
?
Oct 27, 2017 20:29
|
|
|
hey in C# land what is the 'correct' way to store things like connection strings/passwords such that they can't be trivially retrieved through opening app.config/assembly decompilation? i'd google but i'm not quite sure what to look for
|
|
#
?
Oct 27, 2017 20:55
|
|
|
Ciaphas posted:hey in C# land what is the 'correct' way to store things like connection strings/passwords such that they can't be trivially retrieved through opening app.config/assembly decompilation? i'd google but i'm not quite sure what to look for Other than that, you can encrypt your app config, but I'm not sure about that personally.
|
|
#
?
Oct 27, 2017 21:15
|
|
|
Ciaphas posted:hey in C# land what is the 'correct' way to store things like connection strings/passwords such that they can't be trivially retrieved through opening app.config/assembly decompilation? i'd google but i'm not quite sure what to look for you should definitely roll your own solution to this. it’s certain to be secure if nobody else knows how it works
|
|
#
?
Oct 27, 2017 21:42
|
|
|
.net core finally has a decent solution to this https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?tabs=visual-studio not sure if this exists outside of the core world yet. it honestly wouldn't be hard to roll your own as well. the jist is that you keep your secrets in a separate file that lives on the server and outside of your deployment process and you load them at runtime this does not apply if you're app is a client application used locally
|
|
#
?
Oct 27, 2017 22:21
|
|
|
CRIP EATIN BREAD posted:OpenNI2 is really bad because it uses a ton of threads for no reason and bitbangs poo poo over libusb, so I ended up writing a linux kernel driver so that it could stream the data as fast as it was being captured. There was another guy who wrote kernel driver that exposes everything using Video4Linux APIs, but we really needed the raw data and didn't care about getting it in whatever N-bit depth image he was exposing it as. Plus using ioctl to control the camera wasn't all that appealing. i didn't know that but lol, figures. lots of stuff in the ~robotics ecosystem~ is pretty dire and people are really averse to fixing it for some reason. got anything you can share, either re: drivers or project details? stuff sounds neat.
|
|
#
?
Oct 27, 2017 22:46
|
|
|
Glorgnole posted:i didn't know that but lol, figures. lots of stuff in the ~robotics ecosystem~ is pretty dire and people are really averse to fixing it for some reason. If I can dig up the code to the drivers in some old backups, I'll put it up on github.
|
|
#
?
Oct 27, 2017 23:03
|
|
|
simble posted:.net core finally has a decent solution to this Key vault works well outside of .net core too. It's basically just certificate authentication only to access the secrets, and only your production servers have the certificates to access the production vault. Point development servers at the development vault with their own certificates, and the developers don't ever need access to production secrets. I imagine you could use keyvault without using .net too since it's just a certificate authenticated api, as far as I know.
|
|
#
?
Oct 27, 2017 23:07
|
|
|
Ciaphas posted:hey in C# land what is the 'correct' way to store things like connection strings/passwords such that they can't be trivially retrieved through opening app.config/assembly decompilation? i'd google but i'm not quite sure what to look for There isn't? If your secrets are on someone else's computer, that someone else can read them. Anything you do at that point is obfuscation at best.
|
|
#
?
Oct 27, 2017 23:12
|
|
|
darthbob88 posted:Right now I'm using Azure's app strings for the "prod" stuff on my project, and just have a local DB in app.config for my own testing. I've done the app config encryption and it works OK but you have to set up whatever's using it to encrypt it on first run so you have to do it all as plaintext for the first load and then maintain the encrypted config across all future deployments. or reencrypt each time. we have a pretty sweet service at work that handles this for use by using a custom config library that calls out to the service to get credentials when needed and handles all the encryption and authorisation for us
|
|
#
?
Oct 27, 2017 23:19
|
|
|
Glorgnole posted:yeah as i understand it apple basically bought PrimeSense to lock down the concept of "3D depth camera via IR speckle pattern projection" and isn't making a standalone unit to replace all the other sensors that no longer have access to the required components. looks like the tech ended up as iphone x face ID. wow, thanks for the extremely detailed write-up! i knew asking here was a good idea  so basically, i think i'm just going to buy like 3 kinects and their adapters and just hoard hoard hoard
|
|
#
?
Oct 27, 2017 23:26
|
|
|
for a government project the feds were adamant that even though amazon RDS has been approved for federal gov poo poo in govcloud, they wouldnt trust it because "amazon can get the encryption keys" so we ended up using an EC2 instance, using dmcrypt for at-rest encryption, and then at a meeting i explained to them that amazon could technically just take a snapshot of memory and pull the keys out anyways. there was visible panic, and i upset a lot of military CJs who "really wanted to migrate to cloud services" but also "need perfect secrecy an a controlled secured environment"
|
|
#
?
Oct 27, 2017 23:29
|
|
|
go play outside Skyler posted:wow, thanks for the extremely detailed write-up! i knew asking here was a good idea the problem with them in general is that while the chipset is good, the USB layer/chipset/whatever they use is godawful, and is really super sensitive about timing. there was a "sweet-spot" of number of in-flight URBs that had to be cycled constantly or else it would randomly drop data. if you could get a stream of frames from the thing, it worked great, but you ended up having to tune a bunch of poo poo by hand to figure it out. im so glad im not loving around with that thing anymore
|
|
#
?
Oct 27, 2017 23:32
|
|
|
i saw a talk about basically that at strange loop and it seemed like a lot of cognitive dissonance between not wanting to have a physical govt computer but also not wanting anyone else to have a physical computer
|
|
#
?
Oct 27, 2017 23:36
|
|
|
CRIP EATIN BREAD posted:the problem with them in general is that while the chipset is good, the USB layer/chipset/whatever they use is godawful, and is really super sensitive about timing. frankly i'm just looking for a way to detect if someone is raising their hand, or sitting on a chair, and i need to code it without a phd in image processing. it needs to work in a relatively public place
|
|
#
?
Oct 27, 2017 23:37
|
|
|
CRIP EATIN BREAD posted:for a government project the feds were adamant that even though amazon RDS has been approved for federal gov poo poo in govcloud, they wouldnt trust it because "amazon can get the encryption keys" hahah nice
|
|
#
?
Oct 28, 2017 00:33
|
|
|
App.config uses either the machine protected store or the user protected store so anything with access to the respective store, meaning any user who needs to use the app, will have access.
|
|
#
?
Oct 28, 2017 01:14
|
|
|
CRIP EATIN BREAD posted:for a government project the feds were adamant that even though amazon RDS has been approved for federal gov poo poo in govcloud, they wouldnt trust it because "amazon can get the encryption keys" if they needed that then they’d be in the region that offers that EDIT: for reference FamDav fucked around with this message at 01:28 on Oct 28, 2017 |
|
#
?
Oct 28, 2017 01:16
|
|
|
CRIP EATIN BREAD posted:for a government project the feds were adamant that even though amazon RDS has been approved for federal gov poo poo in govcloud, they wouldnt trust it because "amazon can get the encryption keys" the latest AMD CPUs actually include a memory encryption engine designed pretty much for this scenario. it actually looks pretty neat, though it still requires you to trust their equivalent to Intel's Management Engine to be perfectly secure so  .
|
|
#
?
Oct 28, 2017 06:15
|
|
|
i appreciate all the discussion this page but it has left me more confused than before re:Ciaphas posted:hey in C# land what is the 'correct' way to store things like connection strings/passwords such that they can't be trivially retrieved through opening app.config/assembly decompilation? i'd google but i'm not quite sure what to look for The Azure thing made sense, but as usual I'm hampered by working on an airgapped network (e: said airgapping is why no one's given a poo poo about the plaintext pw, also it's an internal app and everyone knows the pw anyway but damnit it offends me) i guess what i could do is use aspnet_regiis to encrypt a copy of App.config (with connectionStrings in) and deploy that with release builds instead of the unencrypted copy, and keep both in the project? idk i've never messed with nontrivial builds/deployment in VS so I'm kinda flailing there, too
|
|
#
?
Oct 28, 2017 07:33
|
|
|
Ciaphas posted:i appreciate all the discussion this page but it has left me more confused than before re: You can encrypt it, but ultimately if an application running on a system can access the secret, then any user with the same privileges as the application can access it using the same technique. Encryption is one way to stop users from just poking around in config files and reading the secrets in plain text, but ultimately they also have to have access to the decryption keys via the application. It really just boils down to deciding what level of obfuscation is necessary based on the sensitivity of the information and the capabilities of your users. If you're concerned that a user of your application could use these secrets to obtain information they should not have access to under any circumstances (even via the application) then your main focus should be to implement more granular permissions via user credentials. A user that should not see certain information should never be given credentials that are capable of accessing that information, even via the application.
|
|
#
?
Oct 28, 2017 14:10
|
|
|
i just remembered we used to also use a really lovely "solution" to app access by putting the credentials in a separate app.config on a remote location that was limited to only allow the account running the [iis] service to access it, the theory being that if you couldn't access that account then you couldn't get the creds. also when we did the "encrypted config" thing i learned that the offshore devs were just typing in the creds plaintext on each deploy and then encrypting on first run instead of maintaining the encrypted section between deployments so they knew them all, defeating the entire point of encrypting it in the first place lmao
|
|
#
?
Oct 28, 2017 15:04
|
|
|
if they already have access to the plaintext creds then its effectively the same thing from a security standpoint. the encryption is the same, but the key is different. also the key protection in the .net/iis rsa protector is identical to the theory behind storing a separate app.config. the rsa keys are litterrally stored on the file system using ACLs to grant machine or user specific access.
|
|
#
?
Oct 28, 2017 15:25
|
|
|
|
| # ? Jun 8, 2024 18:26 |
|
|
Shaggar posted:if they already have access to the plaintext creds then its effectively the same thing from a security standpoint. the encryption is the same, but the key is different. oh poo poo yeah i remember now that it was the remote config thing first then the proper encryption later...then the actual better way where nobody needs access because the creds are outside the config entirely. ofc the original details are still in SVN because nobody knows how to change the passwords without loving poo poo up lol
|
|
#
?
Oct 28, 2017 15:27
|
|