Posts by Roo 1769 publicly visible posts • joined 21 Sep 2010
I spend a significant fraction of my day reviewing reports of vulnerabilities generated by "AI" and lesser tools. Stuff like command line arguments passed into main permitting "injection" attacks etc, and yet here we have one of those very tools with it's pants down around it's ankles taking up the rear from anyone who can open a connection. Bravo.
AI companies eating their own dog food has predictably refined the process down to eating their own dog shit.
I don't really see how you fix systems like NPM & Maven...
1) They make it far easier to pull in unnecessary and dangerous dependencies
2) Consequently they make it a lot harder to for developers to actually understand and reduce the dependencies.
They are working as they are intended to work, I'm not sure how you can "fix" them beyond limiting yourself to a subset of "trusted" upstream repos and hope for the best. Sometimes a bit of impedance to development is a good thing, it's the universe's way of telling you that what you attempting is a bad idea (in this case accumulating a large & complex set of dependencies).
"In other words: common ownership of the means of production (whether physical or intellectual) actually works."
Steady on chap that's practically COMMUNISM ! Joking aside, while I do advocate in putting community before profit, I really do mean that this is about ensuring that a person or organization does not hold a *monopoly* on a form of communication (in the form of source code).
C (and C++) do have something Rust does not: Formal specifications of the language codified as ISO standards. By contrast Rust presents a (slow) moving informally defined target for it's community, rolling out a formal spec of the language & it's libs every few years would give the community a much stronger foundation to use and develop the ecosystem around Rust. This doesn't have to stop the language from developing - standards certainly have not put the brakes on C++. As it stands I don't think there's much to stop Rust from being captured by a litigious corporation (eg: Oracle & Java) and run into the ground with lawsuits and apathy - standards would help insulate Rust from the worst effects of that outcome.
Rather than getting hung up on the language for course, I would be looking judging the toolchains on the following criteria for the build -> upload cycle:
1) Reliability & consistency - ie: if I hit the go button it should *always build and upload (barring errors in my code), I shouldn't be having to dig through the environment to work out why it didn't work this time.
2) Speed of iteration - if I'm learning I want to be able to try things out, being able to build, upload & run my change in a couple of seconds makes this easy. If it takes 30 seconds that becomes dead precious class-time - and frustrating.
I suspect more people will have experience with Python which may also be a deciding factor - but *simple* C with everything in one file should be just as digestible - the problem comes when their coding goes off the rails, C/C++ documentation tends to be less newbie friendly than Python. I was looking for a C++ for beginners tutorial for a colleague recently - I couldn't find anything that really fit the bill - I know this stuff *used* to be readily accessible - but I couldn't find it - the candidates tried to cover every single feature in excruciating detail which just isn't helpful for someone making their first steps beyond hello world. :)
There is a very good reason to reduce memory footprint:
- Power consumption (and dissipation).
The hardware pushes less bits - and because there is less *volume* required to store those bits they don't have to travel as far.
-> More speed, less power
Less data -> less time to process the data.
-> More speed, less power
In the old days to get those benefits you waited a couple of years for a new gen of semiconductor fab process - those gains are no longer to be had - and the speed of light is still the same as it ever was, so if you want to make things faster you need to be more efficient.
I really enjoyed firing up V4, and poking about - it's a marvel - and provides some valuable insights into how dennis & ken put it together. I went on to fire up V7 from the same archive - and oh boy things had changed a lot. Thanks for bringing these gems to our attention - much appreciated. :)
One of the hidden incentives of transliterating code from one language/toolchain to another an incentive to reduce the workload by leaving the cruft behind. Having an AI identify and strip out the cruft should be very doable given the intrusive instrumentation that Microsoft has woven into their platform for many years now.
In practice I found that GPFS has been surprisingly good at dealing with zillions of tiny files - albeit you do need to configure your setup appropriately (eg: metadata heavy for lots of stupidly small files that reek of muppet level programming). The best solution is to not to code like a muppet and pick the right tool for the job in the first place.
W.r.t to the "shorter lifecycle" line: folks are still running RHEL7 and clones to the tune of thousands of instances quite happily. In otherwords: If you want to be you can be just as unsupported and out of date as Windows <11 customers for far less cost.
"The Germans are apparently now publicly looking at alternatives to SCAF. But they've missed the boat. Italy, Japan and the UK have signed the Edgewing partnership - which as I understand it is the industrial partnership structure, with workshare all carved up. Obviously if someone brings more orders, they can get some work - but probably not as much as F-35, which is designed to bring new people in."
While the initial R&D might be already carved up - adding in additional manufacturers is still possible - and I would argue highly desirable for the following reasons:
1) Resilience through second sources - helpful if your plant gets burnt down by a guy who was promised $500 on Telegram in return for torching a critical bit of military manufacturing capability.
2) Proving out production transfer & scaling out - essential for ironing out problems that will inevitably crop up when you want to scale up from a dozen units a year to several hundred or even thousands a year.
3) Ramping up production (quickly).
The manglement strategy here is to cut costs by firing everyone who might possibly be able to create a viable product, leaving himself and the rest of the C-suite to hoover up all the cash & bonuses and license patents. The concept of actually making money from products people want to buy doesn't appear to be a concept he is interested in, presumably because it entails the hard work of nurturing talent and managing people.
The 432 was an ambitious project, but it was way too complicated. Intel just couldn't help themselves from the early 80s to this very day... They just have to make everything as complicated as possible, making the resulting device impossible to validate, awkward to use, slower and more expensive than it needs to be. It doesn't look like they're learning a lesson any time soon too - this cash may as well be boat-anchors instead of life-preservers.
Also worth remembering that Trump has been happy with the results of the elections held under Democratic administrations (2016, 2024).
As for the 2020 election, Trump ran that one, so if it was rigged - it was his fault that it was rigged. No doubt the 2026 mid-terms and 2028 will be rigged as well under Trump's watch because it's clear that he doesn't value or tolerate democracy in any shape or form.
A police officer involved in the case turned out to be one the perps. Not so much lazy policing as a corrupt policeman getting in the way of the prosecution - aided and abetted by lazy right whingers jumping up and down on the sidelines making it a race issue. There are a hell of a lot of data-points that link right-whingers and child abuse. Folks could be forgiven for concluding that the right whingers and their supporters are trying to kick up a fuss to 'torpedo' the convictions of kiddie fiddlers.
Jeez, this article may as well have been written 30 years ago.
It is a damning indictment of the author that they are *still* pedaling this crock after THREE --ing decades and at least *FIVE* major "retraining required" releases of Windows. The costs of using something other than your favourite business lunch provider's products are still "hidden" because you haven't actually gone out and done your --ing job which is to *find* out what those hidden costs are... 30 wasted years - all on the tax payer's shilling.
Give your head a wobble.
I'd say Russia and America are as "Communist" as each other right now under the current regimes.
... A small number of very rich & powerful people get all the pies and the plebs get to work for the rich & powerful people for a little money as they can survive on - ideally less than that, with the risk of being assaulted by state storm troopers and locked up for some random arbitrary reason without due process.
Broadly agree with your post, but ... "The 2 year old process almost certainly means worse power consumption for the same performance" - that has not always been the case. In fact there have been instances where older (tuned) processes are used precisely because they are more power efficient than the bleeding edge.
I do like that xkcd strip - and definitely can relate to it... But as I sit here - right now, as a developer, I realize that somehow I have entered a weird space where the stuff I automated is actually working - and I am casting around looking for more stuff to automate - or in the case of apps saturating virtual machines - migrating them back to bare metal to *reduce* the amount of required automation + cost + ice caps melted. ;)
Weirdly, in the Linux/UNIX space it's the Greybeards that adapt fastest to this idea of bootstrapping stuff with images and tailoring them for the job at hand... Who diagnose the underlying faults in the VM infrastructure that is crippling the code etc... Meanwhile on the other side of the aisle we've got greenbeards(?) who don't understand why they can't run the Java code on Linux Virtual Machines using a Windows jvm.exe. I kid ye not.
Meanwhile the manglement are busying trying to extract their bollocks from the vice of their Cloud vendor having discovered that the Cloud is costing 3x that of on-prem bare metal (2x on-prem cloud), I can bet you can guess what their solution to the problem is: Run those highly-optimized compute intensive batch jobs on 1/3rd the capacity... Throughout all this the greybeard backed teams supporting all this guff have managed to migrate the apps from bare-metal to off-prem cloud, on-prem cloud, and back to bare-metal and mixtures there of.
The greenbeards supporting the cloud stuff are struggling - they keep running into odd-ball VM related bugs and screwing up the configuration while they're at it. It would be nice if they could understand why migrating a VM hosting a HPC app that is eating 100% of the host from one hypervisor to another is a really shit idea for example - their solution is to ask apps to leave 10% of the host unused - which is comical given that the bare metal runs happily at 100% utilization - and the whole argument for migrating stuff to VMs was to improve utilization of hardware...
So cunning you could put a tail on it and call it a Weasel. Oh no, hang on, that's Trump.
Don't you find it weird how all Trump's "cunning plans" involve someone else paying the bills for them ? I call that extortion, and it isn't cunning when playing in the "biglys".
Steve Ballmer called, he wants his FUD back.
Just in case you weren't aware macOS has been at the Desktop game since 2001 - and it's market share is in the same ballpark as Linux - despite wrapping it's developers and users in straitjackets and having many $bns of development budget lavished on it.
Besides which mobile phones are where the action is these days, and Android (aka Linux) is in a lot more people's hands than iOS or whatever they want to call it.
I honestly don't see why you bother FUDding something that has such a small piece of the market you care about. Let the kids have their fun producing software they like using, they aren't in the way of you enjoying a random collection of 90s vintage UIs known as Windows or the different random collection of 90s vintage UIs running on macOS (not to be confused with the 80s vintage UI stuff that ran on Mac OS).
If you are running at any kind of scale you will need a bunch of well qualified SRE/Sys Admin/Operator types to keep your compute estate pointing in the right direction - wherever it runs. With respect to your last comment, I refer you to a paraphrase of quote attributed to John Rollwagen: "A computer is like an orgasm - it's better when you don't have to fake it.".
Cloud SLAs are kinda meaningless when the infrastructure and Cloud services are being continually being overhauled, thus forcing continual development churn just to keep the AWS instances alive. Case in point some of our internal clients migrated to a major Cloud a three years ago - and basically they have an "incident" every other month, much of which is down to the churn and people making mistakes (the odd AWS outage or liquidity shortfall on our 'reserved' capacity happens too).
By contrast the on-prem clusters (even with rolling OS updates, service updates etc) have had *zero* downtime for two years solid (the last incident was literally caused by a back-hoe - but happily the workloads continued executing uninterrupted in the DC regardless). In addition to requiring less overheads within the internal client teams (no Cloud SAs/Operators/SREs needed) the on-prem clusters running costs are less than a third per CPU hour. It really depends on your workload at the end of the day, and ours are very definitely not the classic AWS use-case. Our workloads tend to run 18x6, saturating 100s-1000s servers at a time and the networks get eaten in bursts - we are very bad neighbours. The classic Cloud benefits of consolidating multiple workloads onto a physical host, and multi-region availability don't apply (our workloads are HA by default because you don't get a big enough maintenance window to bounce an entire cluster at once).
It is a case of the right tool for the job... For (our) workloads that span multiple hosts and saturate them for the majority of the day - Cloud has zero benefit - even the liquidity argument doesn't cut it as we found out when our internal clients tried to actually *use* their *paid for* reserved capacity (6 month lead time vs 3 months on prem - and of course that wasn't covered by the Cloud SLA). For the sake of fairness I have to point out that there are plenty of internal workloads that have happily moved to the cloud - just not the big ones we look after. :)
The sad thing is that Gates had promised a database style filesystem with "Cairo" (which was axed in 1996). Longhorn seems to have retrod the path taken by Cairo a full decade before it. Just add it to the pile of ephemeral vaporware that MS used to kill off the competition.
Part of the challenge with OSes in particular is that they are built on hardware - which doesn't necessarily have a formal model, proofs and a means to verify implementations against that model. Thus the OS runs atop silicon quicksand - it can never be proven to be "correct" or "bug-free" because the hardware model it is written against is not adequate - let alone complete in 99.99% of cases. There have been efforts to plug this hole - eg: RSRE's VIPER microprocessor, but as far as I know these methods haven't been applied comprehensively to common or garden x86 type gear.
