> the business owner is aggressively pushing his political views
That's always been the case with Twitter - Dorsey was just as bad, but just with a different set of political views. (Views that, I presume, the EFF is aligned with).
18,824 karma · joined January 17, 2018
That's always been the case with Twitter - Dorsey was just as bad, but just with a different set of political views. (Views that, I presume, the EFF is aligned with).
OP here might be misremembering DVDs, here: the physical media skipped or froze intermittently and the players themselves were finicky; we ended up replacing it about three times in just as many years. Streaming services are overpriced, but they do _work_ consistently.
With 1990's style age "verification" to boot.
Although I've noticed that options have been replaced more and more these days with RSU's (plain old grants) because options have a tendency to go "underwater", suggesting that they weren't all that great to begin with.
That's actually not really crypto, though - that's writing a parser (for a container that includes a lot of crypto-related data). And again... if you import a 3rd-party x.509 parser and you only need DER but not BER, you've got unnecessary bloat yet again.
Again, you run into the attack surface area here. Think about the Heartbleed vulnerability. It was a vulnerability in the DTLS implementation of OpenSSL, but it affected every single user, including the 99% that weren't using DTLS.
Experienced developers can, and should, be able to elide things like side-channel attacks and the other gotchas that scare folks off of rolling their own crypto. The right solution here is better-defined, well understood acceptance criteria and test cases, not blindly trusting something you downloaded from the internet.
Or write your own stuff. Yes, that's right, I said it. Even HTTP. Even cryptography. Just because somebody else messed it up once doesn't mean nobody should ever do it. Professional quality software _should_ be customized. Professional developers absolutely can and should do this and get it right. When you use a third-party HTTP implementation (for example), you're invariably importing more functionality than you need anyway. If you're just querying a REST service, you don't need MIME encoding, but it's part of the HTTP library anyway because some clients do need it. That library (that imports all of its own libraries) is just unnecessary bloat, and this stuff really isn't that hard to get right.
I suspect we're trending back to the pre-personal computing era where access to 'raw' computing power will be hard to come by. It will become harder and harder to learn to program just because it'll be harder and harder to get your hands on the necessary equipment.
Communism/socialism/wealth distribution/planned economies is one potential solution, but it's an awfully ham-fisted one and definitely not one to put into place until it's absolutely necessary. I kind of suspect that a lot of people, like OP, are kind of hoping that now is the time, but it definitely isn't, at least not yet.
All of the collaboration artifice that the author is referring to seems to me to always be a futile attempt to meet "the date". That software development might itself be _inherently_ unpredictable is never even considered, even though there are a lot of reasons to suggest that it is: by definition, the software you're developing has never been developed before, or else you could just use the thing that already exists.
I had a glimmer of hope in the late 90's when the agile manifesto was published - everything about it seemed to me to read "software development activities can't be coordinated like a wedding banquet can, but you can at least make sure that everything is tracking toward a shared understanding". I guess I shouldn't have been surprised when "Agile" became "tell me exactly what you're going to do and how long each step will take" almost the instant of its inception.
You're paying for any of these?