Re: No Lifecycle Upgrades
The real question is in years, no reboots, no disconnections, no crashes, no taking the laptop from the desk? THAT I find it hard to believe.
142 publicly visible posts • joined 19 Nov 2009
Pessimism? You didn't notice we're back in a 1925-1935 sort of thing?
By which I don't mean to imply they should be allowed to win easy. But the risk that they win, even for just a decade or two, is not pessimism at work.
Having learned both at uni, I disagree that C teaches any better. *Pascal* taught better. C is like a circular saw from before the safety covers were invented. Cuts just as well fingers and wood. I'm sure Moxie has a list of exploits due to lack of those safety covers that's longer than I am tall.
That's literally the root of all evil for C and C++
In your hands, they do fine (for a decent value of "fine", as you have complaints too).
And "give full control to the developer", the much vaunted philosophy of the languages, works fine *for excellent developers*. On their good days, anyway.
But I got out of uni 22 years ago, and I still have to meet people who are excellent developers a significant number of days of the month, whether I look in the mirror or not. Perhaps I need to keep better company, but the truth is that there aren't enough good developers, and therefore tooling needs to avoid the dangers.
Plugging my android phone on my windows worl laptop and activating the usb tether creates a network device that claims 433 mbps. *Claims*, I haven't had a chance to verify that, since the 4g uplink was never faster than 50.
Might not be as fast as the latest wifi but it ain't bad either.
So in their opinion I come to the shop, install all the stuff required for the typical builds I do during the day, THEN complain that 8 gig aren't enough for my needs, when I know the builds will take more than that and memory compression can't get far enough?
"We are much more efficient in memory use", yes but zipping data has limits not even Apple can break and not all the software I use is written by Apple, especially that which is written by me, and making all the changes needed to be the best M3 native app, with the lock in that brings, is a bit much when all I needed was 32 gigabytes of RAM.
I fixed a 3.5 inch floppy drive with a similar application of sharp blades.
Brand new PC (tower case) wouldn't write or read fro floppy. Year about 2001. My uncle gave me a ring about it two days after he bought the thing.
Much messing about looking for loose cables, at some point we had the thing on with the case open and its front off. To our surprise, floppy worked fine. Front back on, floppy failed again.
The front had a plastic facade in front of the floppy and a thingamajig to allow the operator to push the eject button on the actual drive. The thingamajig was about two millimetres too long and would keep the button half pressed when the front was screwed on. Snip snip and all was well.
When I told my dad I wanted to study computer science, he said: but why? The things have been built already.
Same as "Write it right the first time"
Funnily enough, in his daily job* he was very well acquainted with "needs change, things get old, stuff breaks". He'd even joke half his work was fixing the stuff he'd built twenty years before. Microsoft has just made a business that ensures things break at scale, instead of at their usual pace.
* he was a plasterer before retiring
Fine grinding? Remote location? Waste of energy.
Chuck them in a spare steel container and leave it wherever. In a hundred million years it'll be a nice lump of easily mined minerals, with lower chances of poisoning the local ponds.
But if you wanted to finely grind DRM proponents, I shall start carving out the millstones.
Only code that uses APIs that have been dropped is complicated to move. Complicated in a corporate sense, I urge to add: release and change management, specifically. I've updated a few code bases over the years, changes required have been minimal. Changes prompted by IDEs and static code analysis tools, plentiful - but those are suggestions. Often good ones, yes, but not necessary. Avoiding a 3 million bill, on the other hand...
That's not a good argument. As you note, basic protocol needs to know the IP address of the request originator (for the purpose of returning a response, if nothing else), so, forbidding the sharing of that information without consent wouldn't allow for anything to be served, including the page that asks for consent.
Tracking IP addresses requires consent; that's not the same thing discussed here, and it requires storage of the data.
A company can *say* they don't store it, but words are cheap and lies can cause expensive lawsuits. That's why there are certifications and audits and that sort of stuff. Not perfect, but that's all we have.