You might have done barely working duck-taped Bash scripts; not eveyone who calls themself a 'system admin' is competent. But actual professionals who ran these systems since the 1970s had carefully written, fully functional scripts and we were quite capable of keeping hundreds and thousands of servers running just fine. Being bad at your job isn't the tools fault.
All Bash scripts are duck-taped by definition. It's a shitty duck-tape language.
> thousands of servers running just fine
Err yeah well you might have noticed these things called "laptops" and "desktops". SysVinit was... fine.. on servers. It worked badly on desktops and not really at all on laptops. I'm pretty sure the post introducing SystemD explained it all in detail if you want to learn something.
This. I can see the utility of systemd and probably would have liked to have it when my team was riding herd on a DC full of Sun E15Ks and HP Superdomes. But for basically everything else that I use Linux for, every time someone says "systemd does this", at least 50% of the time I don't need that, and most of the rest I could do with with other tools with vastly less complexity.
Not "this". By that logic most people do not need backups too. Rebuilding working service state after config change is non-trivial, requires using admin-only kernel interfaces, and said kernel does not care about these types of problems. Meaning average user ends up simply rebooting rather than trying to figure why enabling wifi makes printer stop working (and such). We cannot have network stuff controlled by multiple programs, because linux kernel is broken like that. This thing is the userspace part of the monolith.
The XG series switches? Force10 sold them until Dell bought Force10 and continued to sell them (although the firmware changed a lot along the way). They were, AFAIK, pretty popular in the US under the Dell brand.
My home network is XG2000 10G core and a few XG0224 1G/10G dist. Very nice switches.
Ubiquity proved you can bust into the market from the bottom end if you want. Nothing was stopping them from doing the same but like many companies they prefer to focus on how much money they can siphon from the Fortune 1000 so I can't say I feel sorry for them.
I'm not sure why that's relevent, particularly since Ubiquity's approach wouldn't have remotely competed with Fujitsus custom ASICs if they were actual contemporaries, but you clearly have an agenda you're in love with, so...ok, sure.
You apparently don't do business out here with the unwashed masses where "whadda mean with all that nonsense? It's cloud...it's by definition safe[1][2]!" is an all too common preconception.
[1] That's a quote, including the Boston accent.
[2] The only one I had that was better was a C-level who said "why are you asking for all this money for security in Azure. It's Microsoft so it's already secure.". That, too, is a quote.
and start talking about where administrative access and encryption keys lived
Yeah, that was/is just another problem. Considering how that was actually handled in the real world before data residency laws came into force, I'm glad 'we' didn't convince those countries to put their citizens data at risk.
I'm disagreeing with you. I in the before time, I had all sorts of conversations around this topic with any number of cloud providers that were like:
Us: We are concerned about our citizens (US) data, how are you managing the databases.
Clout Provider (CP): They are only managed by fully background check employees.
Us: Yeah, but where are they? What is their citizenship?
CP: Um...mostly Eastern Europe. Lots in RU. (another CP proudly said "they're pretty much all in China...for cost containment").
Us: ...
Us: We are concerned about our citizens (EU) data, how are you managing encryption?
CP: Everything is perfectly encrypted with hardware HSMs and all the FIPS and stuff.
Us: So...where are the folks who run the HSMs?
CP: Um...mostly SV. Some in the EU.
Us: But can you assemble a quorum of US citizens for the HSM?
CP: Of course!
Us: ...
And on and on. Not to put too fine a point on it, many of us have no faith that vendors self policing international data protection in the face of government level pressure on companies and employees would work. Not that it can't, I don't think it would.
(I like the accidental pun of "Clout Provider" btw, which sadly conveys some of what they try to imply).
We may not be disagreeing that much. My argument was, and is, it's not about where the data is, it's about who has control over it. The counter-argument was "well if it's in another country, then we don't have jurisdiction, so it's going to be much harder". But what you need jurisdiction over is the people. Otherwise, you end up with multi-national corporate end-runs where you have shonky companies offering to store data locally, but who knows what department has control and access.
To be fair, the context I was having these conversations was countries arguing for data residency to combat the threat of mass surveillance (corporate and governmental) in the US, and the limited protections their users had relative to US nationals. But again, the problem is that it assumes that jurisdiction remains territorial: which is not how this was ever going to play out. The next wave after data residency requirements, beyond the usual extraterritorial intelligence community actions, was laws like the US CLOUD Act, the UK's Investigatory Powers Act, and Australia's TIA law, which effectively attempts to provide regular government departments and law enforcement with the legal ability to access data that would technically be on foreign soil.
My point was not that corporations should not self-police, but the concept of "it's stored here so we can oversee it" is not as clearcut as it seemed, and it risks introducing a new level of complexity to resiliently storing data. Which may be worth the price, but was never considered at the level this was discussed.
That's fair, and it sounds like we aren't that far apart. It is, in fact, about control. So I'll restate my central theme as "until the idea of enforceable data sovereignty requirements were enshrined in law, the cloud providers did not and would not delegate control of any body of data to 'controllers' that weren't in jurisdictions where they could be influenced/coerced to compromise that data". Was this a slippery slope/camel in the tent? Well...that's politics and it didn't have to be, but I see your point. But the reality is the push for data sovereignty wasn't done with the intention of enabling totalitarian follow-on legislation and it wasn't in and of itself a bad idea.
Yep, exactly. There's a peculiarly unsatisfying kind of vindication that comes from making "slippery slope" arguments, and then watch them play, and now you are now both a) technically correct, and b) fucked. You'll excuse me if I have a brief "I told you so" moment about a scenario about Amazon's UAE datacenters being bombed without bakcups because of a US-instigated Iranian conflict, where -- if I'd ever dared to describe it -- would definitely have got me laughed out of those rooms in 2010.
You're saying (correct me if I'm wrong) that data sovereignty laws are unconditionally bad because they inevitably lead to totalitarian followon laws and there's nothing to stop them. I'm saying if we didn't have enforceable data sovereignty laws we would be in worse shape for data privacy and we should have prevented the followon laws from coming to be (and, true enough, we didn't).
Further, the UAE datacenter issue is a red herring. It's an engineering issue not a political one (data sovereignty without physical redundancy is...stupid?), but schadenfreude is a helluva drug.
No, I'm making no "unconditionality" claim here: there are just risks and benefits. Sometimes you're the person in the room highlighting the potential problems. The risk with doing that is that when those problems don't happen, you look like a fool. But someone should raise the problems anyway, because that's part of the risk assessment!
Of course, if the problems do happen, then you get to indulge in "I told you so". But only if you failed to convince anyone at the time.
While I don't disagree with you, they shouldn't have to. This should be one of those things like covering your mouth when you cough in a crowd and not playing loud music in your cube that people with basic social skills should know not to do. Unfortunately, like much basic courtesy, we apparently now have to make rules.
I agree, but it seems that some people actually need to be told that copy/pasting a bunch of LLM slop into chat is like farting on an elevator.
I wouldn't even say that it comes down to "social skills" in a lot of cases, it's just people who seem to be performatively using AI. I'd classify them as corporate climber "yes, boss" types more than lacking in social skills.
What is 'insane' here is the shear level of entitlement displayed here, including lumping a niche, free, volunteer supported service in with billion dollar, for profit corporations and demanding they pander to your inflated expectations.
It doesn't matter who or what the service is, how much they have, or whatever else. They created a problem and now users have to pay for the inconvenience by emailing(!) specific details that could be captured automatically through web logs: OS, browser, IP address. It's ridiculous.
> details that could be captured automatically through web logs
You can't be serious. Are you ok? The entire point is that they're trying to tell bots and humans apart. They're trusting email (and how you write your email) as a good signal that you're human. What are you talking about getting it from the log? The point is to correlate. How do you expect them to know who you are in the log unless you give them that info?
> They created a problem
No, they're dealing with a problem, and compromised that some human users may unfortunately get blocked.
> and now users have to pay for the inconvenience
You don't have to anything. You can just not use them. They don't owe you their service.
Somebody is handing out free apple lollipops, they ran out, compromised on giving grape ones, and now you're complaining you're being forced to eat a grape one and you don't like grape. Don't eat it.
If we're looking at 'future' filesystems, is fragmentation really an issue in an SSD world? Not that there isn't a lot of spinning rust (and will be for quite a while), I don't think it's unreasonable to assume "most block storage is going to be SSD in the future" when allocating resources to priorities.
The day I can furnish my NAS in SSDs for roughly the same price as HDDs probably won't come before any current filesystem is obsoleted for some reason or another, methinks.
reply