> They should be fined out of existence for such breaches and they would quickly change tune.
Looks like this is a great opportunity for an object lesson. Let’s see how it goes…
As far as certification stuff…
Civil engineering has had licensing forever. That’s because Bad Things Happen, when they make mistakes.
I do think that it would be a good idea to score/certify critical infrastructure stuff. That might involve certification of the people that make it, but it should certainly involve penalties for the people responsible. That might include the authors, but it should probably also include the folks that decide to use the bad code.
I know that ISO 9000 is an attempt to address this kind of thing. In my opinion, it’s kind of a mess. I’ve worked in ISO 9000 shops, and it’s not much fun. The thing you learn, pretty quickly, is how to end-run the process, as it’s so heavy, that it basically stops all forward progress. It doesn’t have to, but often does.
Mistakes get made. If you design carefully, these mistakes won’t cause real damage.
I just figured out that an app I wrote, that’s been out for two years, has an embarrassing bug (mea culpa). I’ll get it fixed today.
Because I’m pretty careful, it doesn’t affect stuff like user privacy. It just introduces performance overhead, in one operation, so the fix will mean that the app will suddenly speed up.
I’m not sure that certification would have solved it. My security mindset is why user privacy wasn’t affected, and that comes from experience.
> Good judgment comes from experience. Experience comes from bad judgement.
Also if you are personally liable of gross negligence, you will:
1. Get paid more (as less fake "engineers" are available for the responsibility).
2. Push back harder (or at least document in detail) on malpractice during development. Manager did not listen to your warnings? Document it and when shit hits the fan, the manager gets the stick instead of you.
Hitting companies with monetary fines does not work. Hitting the employees with jail time will make sure they don't sign on dangerous or known problematic systems.
Manager not listening? Remind them they will face a trial if the issue does surface.
I do this on my iPad with Magic keyboard and I'm a die hard command line user otherwise.
I think the reason I started doing it on the iPad is that the keyboard focus is sometimes inconsistent, so clicking or tab-tab-tab-enter is slower and less reliable vs. just touching the screen. Definitely feel the gorilla arm though.
Exporting originals just hangs for me. Opening or switching a photos library is basically hoping the Mac doesn't crash. Edits are locked inside the database, with no hope of ever getting them out. And god forbid you put the library on an external drive - never unplug it! It's a horrible piece of software.
I regularly back up my Photos library using rsync to prepare for the worst. From the files I see it looks like all the originals are there under /originals, albeit renamed to some UUID hash. However the EXIF data and contents seem to be intact. The number of files and their names are also stable. The database seems to be a basic sqlite DB.
I think it might make sense to extract the files directly that way, and try to see how the DB stores the original filenames. Might not be too hard. The edits though I think are applied "live" (at least for video) so it's probably impossible to get them out this way.
I agree. I've known how it works for years, and I think the current setting is a cop-out.
In TFA it's set to a measly 2MiB, yet tried to allocate 2TiB. Note that the PG default is double that, at 4MiB.
What the setting does is offload the responsibility of a "working" implementation onto you (or the DBA). If it were just using the 4MiB default as a hardcoded value, one could argue it's a bug and bikeshed forever on what a "good" value is. As there is no safe or good value, the approach would need to be reevaluated.
The core issue is that there is no overall memory management strategy in Postgres, just the implementation.
Which is fine for an initial version, just add a few settings for all the constants in the code and boom you have some knobs to turn. Unfortunately you can't set them correctly, it might still try to use an unbounded amount of memory.
While the documentation is very transparent about this, just from reading it you know they know it's a bad design or at least an unsolved design issue. It just describes the implementation accurately, yet offers nothing further in terms of actual useful guidance on what the value should be.
This is not a criticism of the docs btw, I love the technically accurate docs in Postgres. But it's not the only setting in Postgres which is basically just an exposed internal knob. Which I totally get as a software engineer.
However from a product point of view, internal knobs are rarely all that useful. At this point of maturity, Postgres should probably aim to do a bit better on this front.
Yes exactly. Although I didn't buy a new guitar, but a dozen tuners. It finally clicked when I got one that was "real time" enough to see how the tuning shifts from high to low. This was before smartphones could do it.
Doesn't help that most tuners are still dog slow, none of the beginners courses properly tell you how the guitar actually works, or what a "chord" really is. They're all just "play this and don't worry about it". To be fair it does get you going.
Using an M2 8GB Mac Mini, I only ever ran into problems when trying generative fill in Photoshop. There I get insufficient memory errors if the selection is too large.
Old too, and in my experience that was often slightly more work than fixing the bugs in my own implementation. I did swap out a borked module in the build an OS class once but otherwise used my own.
Sounds very grim. I live in a snowy part of Europe and very little of this applies, except the stay dry and warm part. Here are 2 things I learned:
1. Do what everyone else does, when they do it. And don't, when they don't. You could die.
There is usually a reason even if you don't understand it right now. You don't want to find out why when you're out in the cold and freezing.
2. Buy gear locally.
There's sometimes reason a certain item is on the shelf and not the stylish one from California, or the super heavy-duty one from Norway. Unfortunately, often this is only obvious in hindsight. Does not depend on price, but it does apply across the board from clothing to cars.
I'm in California. We have good cold-weather gear, you just have to get it from the right kind of store, specifically one that supplies outdoor workers.
Maybe California is a bad example. What I'm getting at is the selection for what you need is usually larger and more applicable to the conditions locally.
I see plenty of tourists with winter gear that is either insufficient, or completely over the top. Whereas if you buy locally you'd generally find the right stuff.
I think the bigger problem is that many of the tourists don't normally spend time outside, so they are used to only having enough gear for a heated building or car, even at home.
Thats the problem right there. The company doesn't care. No amount of personal certifications is going to fix that.
It MUST be on the companies. They should be fined out of existence for such breaches and they would quickly change tune.
reply