Posts by F. Frederick Skitty 475 publicly visible posts • joined 12 Jan 2022
Vance doesn't have the MAGA cult fully behind him, at least not yet, and there will be a lot of backstabbing going on when Trump croaks. The likes of Waltz, Miller, Gaetz and Rubio at each others throats but without the weird charisma that appeals to the morons that voted for Trump. I'm actually looking forward to it, as it will probably tear the Republican party into at least two separate parties.
I wonder if the Openstack codebase could be repurposed as an AWS compatible layer that could then sit on top of a European cloud alternative. Given that a lot of the underpinnings of AWS are open source as well (Redis, Opensearch, the various RDBMS) it should be feasible and reasonably quick to get up and running if the will and resources are there.
Well said. In my last job we had a team working in Kyiv. Our head office in Switzerland contracted a specialist outsourcing firm in Ukraine that sets up and staffs a subsidiary that is then owned by the client.
Great people, really well organised and they produced high quality code. I kept in touch with a few of them as we got acquainted on visits between London and Kyiv. Sadly two of the non-technical staff have been drafted into the army thanks to Putin's imperialist war.
I have a strict rule that I do not sort out computers for friends or relatives. This rule is because I used to reluctantly help them out until the time I discovered vast amounts of very nasty porn on one computer - the filenames scrolled past as I was backing the machine up, and they were descriptive enough that it ended my friendship with the machine's owner.
At my first employer they did a test of the diesel generator one day. It spluttered into life for a few seconds and then cut out. Turns out the only fuel in the thing was whatever had been in the fuel lines since last time it ran. The huge tank that should have been full of diesel was empty, presumably drained by local ne'er do wells.
"GPL is about using the copyright system to maintain freedom".
In Stallman's case it's more like using copyright theft to start a side hustle. He stole the code for GNU Emacs from James Gosling and a couple of other guys who had been working on it. Stallman stripped their license headers and claimed it for his own.
I regrettably hosted Stallman in my home almost thirty years ago when he was in the UK and his previous accommodation arrangement fell through. He was an ungrateful bastard and an utter creep around women when my local Linux user group took him out for dinner.
He speaks German very well, having learned it before his posting to East Germany during the cold war. A translator is still useful for situations where precise language is required, and I'm quite sure any translators working for high level politicians have very specialised training for intelligence purposes. They probably monitor subtle "tells" in speech and body language. Putin is known for his very controlled body language and lack of emotion (grasping the table or chair arms for example to minimise movement) when negotiating, but can turn on a very colloquial form of speech when speaking to the general public.
Last time around Trump mentioned something in public that was from a confidential briefing and destroyed an intelligence gathering operation.
We still don't have full transcripts of Trump's meeting with Putin in Helsinki after the stenographers were made to leave the room leaving just the two scumbags and a Russian translator.
So a narcissistic, arrogant moron being manipulated in private by an ex-KGB operative and a translator who no doubt had FSB training. Hopefully the Finns were listening in*.
* They have form for this, the only known recording of Hitler speaking in his normal voice is from a meeting with Marshal Mannerheim that Finnish radio operators eavesdropped on. Hitler discussed quite frankly the problems the Germans were having, which is quite interesting.
I've got two editions of the TMR Ellis book on Fortran programming, and I think they were pretty much the standard text at universities in the UK for a while. I'm kind of fascinated with the language after having to fix an issue when the company Fortran guru was off work with a long term illness. One of our clients still insisted on running the older software from before it had been ported to C. This was Fortran (or FORTRAN at the time) 77 with vendor extensions but still in the fixed column format rather than the later free form one.
Trump's grandfather was also a brothel keeper in the gold rush, at least until he scarpered because he owed people money. Sounds like Donald inherited his grandfather's business acumen rather than his grandmother's (she was the one who founded the family business with Donald's father fronting it due to misogyny).
"Every other council in the country can implement these systems effectively"
No, no they really can't. My local council still does a lot of it's work on what they call "analogue" systems. Paper based in other words. Nor are they alone, with 40% of UK local authorities still mostly paper based, despite many spending vast sums on projects to try and go digital.
The fact you had to write your own smart pointer proves C++98 didn't provide safe alternatives to traditional manual memory management. And I have enough C++ books on my shelves that describe the remarkable complexity of trying to write a decent smart pointer to suspect your implementation was as subtly broken as most were.
No other language seems to have so many books describing the subtle and not so subtle gotchas as C++ has. Add in the arcane delights of template meta-programmimg along with the massive changes in each C++ standard and it's no wonder so many C++ codebases are maintenance nightmares.
"Genuine question. What stops a compatible Linux that is written in Rust?"
A major disincentive is device drivers. The majority of code in the Linux kernel consists of drivers, and this broad support for hardware is a major attraction. There is no stable API for drivers in Linux, so even if you tried to leverage the availability of Linux drivers in your hypothetical Rust kernel you would either:
1. Be forever playing catch up to API changes across all the Linux subsystems.
2. Forking and maintaining drivers.
A massive maintenance burden either way.
I'm not aware of any pre-existing languages that were on a similar level to C - it's direct predecessors B and BCPL certainly weren't, as they only had one data type. C has often been described as a glorified assembly language, and there is definitely a lot of truth to that. At the time there was a large gulf between assembly language and higher level languages like FORTRAN, COBOL, APL, PL/I, etc.
At my first employer in the mid 1990s we had a department that built PCs for company use as well as for customers. The latter included CD-ROM jukeboxes for our data products and it was cheaper to build from components than source pre-built systems. One of the juniors was caught stealing RAM, typically half the allocation for each system. He was charged and convicted, although got off lightly with a suspended sentence and community service.
He was only still in a position to carry out the thefts thanks to nepotism. He was the nephew of a senior manager, and had already survived an encounter with HR after he was caught cracking one off to early interweb smut. It was after regular office hours when I was working late - I was on my way to the coffee machine when I saw the lights on in one of the offices, went to turn them off and to my disgust discovered the little twerp burping his worm.
There's a kind of tension in the Linux kernel world as it's never had stable kernel APIs. On the one hand, having stable APIs means less maintenance for those using them for things like drivers. On the other hand, backwards compatibility with APIs that turn out to be less than ideal can hinder development of the systems sat behind those APIs.
It's one of the things that has been a big problem for Microsoft. I'm not a fan of their products, but they have gone to great lengths to maintain backwards compatibility. That has come at a cost of improvements that would have potentially improved their own products.
Neither approach is fundamentally wrong - it's hard to get an API right, while breaking an API in a new version is tough for the users of that API. The Rust on Linux people are struggling with the Linux approach of preferring to improve - or at least change - kernel APIs. Perhaps it's better they focus on an environment like Redox OS where those changes aren't dictated to a considerable degree by the underlying architecture being based on the semantics of the C programming language.
Thanks for the thoughtful response rather than just a down vote. I should have also mentioned the Redox OS project, a ground up implementation of an operating system in Rust that's lead by a guy at System 76. Maybe it's the best place to focus Rust development for a potentially more memory safe implementation of an operating system kernel as that project has made impressive progress in a short time.
It seems to be a common view amongst the Reg commentariat that Rust is snake oil and its proponents are pushy chancers. I get it - I have thirty years of experience in software development that have imbued me with a deep distrust of people offering silver bullets for our software engineering problems. I'm also aware that the term "silver bullet" accompanying a technology that over promises but under delivers predates my time as a professional programmer since I have books by the likes of Fred Brooks and Brad Cox that discuss it.
However, I feel Rust is seriously misrepresented on these forums and that the Rust for Linux project is particularly maligned for the wrong reasons. I've followed the evolution of both the language and the attempt to get it usable for Linux kernel development with interest, since as much as I love C (after all, it was the first programming language I properly learned) I'm painfully aware of its shortcomings.
The Rust for Linux folk knew they faced an uphill battle to get support for it in the kernel, but they probably assumed they could succeed on merit alone as long as they minimised the burden on those with little to no interest in it. What they probably didn't expect, and seems to be playing out, is how downright obstructive some subsystem maintainers would be (Hellwig and Ts'o in particular). The Rust folk have acknowledged they can't make demands on those maintainers to give concessions to their specific needs, and as a result have shouldered the burden of keeping Rust bindings separated while dealing with the fluid (some would say downright unstable) APIs of those subsystems.
Frankly, I'd prefer the Rust for Linux folk to just say "fuck it" and focus instead on something like the FreeBSD kernel, as at this point it feels much more like a meritocracy than the Linux kernel development world. The fact is though that Linux has far more momentum and therefore broader hardware support, so I can understand why it is the more attractive proposition for innovation.
It was in 1996, as I can recall which company I was working for at the time and they had allowed me to experiment with Linux as a possible platform to port our in house SunOS applications to. I can't find a mention of Sun sending out CD-ROMs, but I did find an article about the beta being free to download from Star Division themselves. I can only assume Star Division and Sun were keen to encourage desktop use of Unix and Unix like platforms at a time when Windows NT was starting to take off:
https://linuxgazette.net/issue09/staroffice.html
Contrary to the accusation from weirdo commenter GNU Enjoyer that Sun supposedly "attack[ed] people with [their] proprietary software", I remember them being extremely encouraging towards open source software. For instance, they gave John Ousterhout free office space to work on his Tcl scripting language and Tk graphical toolkit. Another example would be their NFS code that was then integrated into several open source Unix like operating systems.
For a brief period Sun offered StarOffice for free, sending it out on CD-ROM to those that wanted it. This was a few years before they bought Star Division who made StarOffice. I don't recall whether it was for more platforms, but definitely Linux. It was the first version to support Linux, 3,.1, and it was the version with an interface based on the Motif GUI toolkit. It was lean and fast, with a very clean and uncluttered appearance. A couple of years later it had been ported to a new GUI toolkit and had a weird portal thing that was trying to be a sort of replacement desktop. Thankfully the portal was eventually junked, probably with the first version Sun released after acquiring Star Division.
The actual work to try and make the out of the box system work for it's intended purpose is invariably carried out by an a Oracle "partner". That will be a third party with an interest in pushing more Oracle products as they get a nice fee from Oracle, but they are otherwise independent of Oracle. That means Oracle are insulated from the potential penalties in the contract to deliver a system (although the civil service and most private enterprises are terrible at writing penalty clauses that can effectively be enforced).
The frustration with this system is that it is intended to replace one that works. They usually get replaced because the core software is no longer supported by the vendor and the vendor makes it impossible to maintain or extend the system any further. So it's a rip and replace rather than evolving the existing system. Government needs to start getting serious about building systems based on open source foundations, and funding adequate ongoing development to keep them up to date.
In my experience, it's eminently possible to evolve a system based on an open source foundation for decades. The main system I work on is just that - 25 years old (a core "modular monolith" and several dozen smaller applications) with hundreds of thousands of lines of code. It runs on the same foundation it started with, Java and PostgreSQL. The biggest change was replacing a custom IoC container with the Spring Framework then eventually Spring Boot, and it runs on the latest stable PostgreSQL.
The knowledge to build horizontally scalable, well layered and modular systems is hardly new, although it seems each successive generation has to learn some of the same mistakes (the hideous "microservices" architecture to give a recent example). Perhaps governments need to bring development back in house and foster knowledge transfer as each new generation of developers arrive.
I still muck about with vacuum tubes, or valves in British parlance, for guitar amplifiers. That application uses just a handful in each device - the amount of heat 1,000 of the things would produce is astonishing. Although it does lead to a great anecdote about the female operators of the Colossus computers at Bletchley Park working in just their underwear because of the heat!
No, Linus had some very good points about why C++ was inappropriate for the Linux kernel. You can only use a very small subset of C++ features in the core kernel subsystems (no exceptions, no STL, etc) at which point, there's very little benefit but a lot of complications to supporting C++. The issue is less clear for drivers, but even there you cannot use a lot of C++ features since they don't play well with the quirks of a lot of actual hardware. That's also why C is a lot more common for embedded systems than C++.
Maybe, just maybe... Some of the rust people can team up with the current maintainers and just go, "Let me handle all the Rust aspects of this."
That's exactly what the current situation is. The Rust developers are maintaining bindings to the existing C API. Hellwig is just being an arsehole.
Wow, ignorant much?
Java has bugger all to do with JavaScript - the similar names are down to a deal Sun Microsystems did with Netscape.
As for C#, it was a Java clone after Microsoft's Visual J++ fork of Java hit the buffers. To be fair to Microsoft, it gained some good features (and some terrible ones - the Active Record anti-pattern for starters), but ultimately made Sun and then Oracle up their game.
So you stick to your language and environment that is still essentially a Windows only thing once you get beyond the basics. Me, I'll stick to a fully featured stack of Java and Spring Boot that I can run on an operating system that isn't a sack of shit.
"The new administration will force companies to build chips domestically through the imposition of tariffs".
Wow, are Forrester really that crap at their job? Those fabs would take more than a decade and billions to build, even then they will have terrible yields for a long time since that's the nature of such facilities.
Trump's going to be long out of office and long dead before that would happen. So the US tech firms will sit out the next four years or move abroad instead, since why would they invest in US fabs that are never going to be able to compete with the likes of TSMC on quality or cost?
Then there's the problem of the lithographic tools such fabs depend on, all patented and made in a European Union that will see a great opportunity to screw the Yanks by banning their export to the US or only after adding eye watering export taxes to them.
The accounts from family members and his academic contemporaries is all on the side of Trump being as dumb as a rock. He was sent to a military boot camp type of school after the administration at the regular fee paying place his family was used to sending there offspring to informed his father that he was no longer welcome. Private schools may love the fees, but they need the reputation from their students getting good grades far more and it soon gets out when the less then stellar students get to a big name university if they help them get there. He allegedly got into Wharton only after his elder brother had a word, and was far ... very far ... from the stellar student he makes out he was.
Fact-Checking All of the Mysteries Surrounding Donald Trump and Penn
Autarchy (posh name for economic self sufficiency) was a big thing with past generations of fascists. And before some plonker mentions Godwin, check the parallels between Trump and previous fascists. Trump's talking about expansionist policies such as incorporating Greenland into the US, by force if necessary.
I've had a recent poke around in the Enlightenment library repos, and the code is still shocking. Just for starters, things that are supposed to be abstractions often mirror the implementation and quirks of what it was first written to support - the X Window System libraries - rather than being really cross platform.
The documentation is still incomplete or entirely missing for some significant parts. What actually there is often out of date, misleading, outright wrong or just poorly written (grammatical errors, awkward and confusing phrasing).
One major problem with writing anything using the EFL is the project's habit of deprecating or just entirely replacing big bits of it with no porting guides. It feels more like a playground for hyperactive coders than a reliable framework, which would be fine but it's also supposed to be the underpinnings of Tizen development!
Since a lot of the clones are in an entirely different form factor (Mooer pedals are tiny compared to the ones they are based on) the PCB has to be different to the original. In fact it's so easy just to tweak a layout to make it substantially different to the original that a clone maker would be mad not to do it. For IT folks, this is more akin to the PC clones of yesteryear than some kind of knock off that's pretending to be the original. As for not understanding the way it works, the guitar pedals we're talking about here are simple - incredibly simple in the case of overdrive, fuzz, distortion or boost pedals. Even stuff based on delays (which includes things such as chorus or flangers) are based on a handful of bucket brigade ICs with very generic supporting circuits.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
