The Fediverse by design prevents this, while the internet of the old age had little if any guardrails against this specially since the platforms never really federated with another.

I see someone is too young to remember USENET.

The Fediverse is a bit more like the old USENET days in some regards, but ultimately if it ever becomes more popular the same assholes that ruin other online experiences will also wind up here.

What made the Internet more exciting 30 years ago was that it was mostly comprised of the well educated and dedicated hobbyists, who had it in their best interest to generally keep things decent. We didn’t have the uber-lock-in of a handful of massive companies running everything.

It’s all Eternal September. There’s no going back at this point — any new medium that becomes popular will attract the same forces making the current Internet worse.

Depends on what you mean by “back in the day”. So far as I know you could be ~30, and “back in the day” for you is the 2005 era.

For some of us “back in the day” is more like the early 90’s (and even earlier than that if we want to include other online services, like BBS’s) — and the difference since Eternal September is pretty stark (in both good and bad ways).

There are a lot of manufacturer-agnostic smart home devices out there, and with just a tiny bit of research online it’s not difficult to avoid anything that is overly tied to a cloud service. Z-wave, ZigBee, Thread/Matter devices are all locally controlled and don’t require a specific companies app or environment — it’s only really the cheapest, bottom-of-the-barrel WiFi based devices that rely on cloud services that you have to be careful of. As with anything, you get what you pay for.

Even if the Internet were destroyed tomorrow, my smart door locks would continue to function — not only are they Z-wave based (so local control using a documented protocol which has Open Source drivers available), but they work even if not “connected”. I can even add new door codes via the touchscreen interface if I wanted to.

The garage door scenario can be a bit more tricky, as there aren’t a lot of good “open” options out there. However, AFAIK all of them continue to work as a traditional garage door opener if the online service becomes unavailable. I have a smart Liftmaster garage door opener (which came with the house when we bought it), and while it’s manufacturer has done some shenanigans in regards to their API to force everyone to use their app (which doesn’t integrate with anything), it still works as a traditional non-smart garage door opener. The button in the garage still works, as does the remote on the outside of the garage, the remotes it came with, and the Homelink integration in both of our vehicles.

With my IONIQ 5, the online features while nice are mostly just a bonus. The car still drives without them, the climate control still works without being online — most of what I lose are “nice-to-have” features like remote door lock/unlock, live weather forecasts, calendar integration, and remote climate control. But it isn’t as if the car stops being drivable if the online service goes down. And besides which, so long as CarPlay and Android Auto are supported, I can always rely on them instead for many of the same functions.

Some cars have much more integration than mine — and the loss of those services may be more annoying.

I certainly wouldn’t run to HR right away — but unfortunately, it’s true sometimes that people just aren’t a good fit for whatever reason. Deadweight that isn’t able to accomplish the tasks that need to be done doesn’t do you any favours — if you’re doing your job and their jobs because they just can’t handle the tasks that’s hardly fair to you, and isn’t doing the organization any good — eventually you’ll burn out, nobody will pickup the slack, and everyone will suffer for it.

My first instinct in your situation however would be that everyone has got used to the status quo, including the staff you have to constantly mentor. Hopefully if you can coach them into doing the work for themselves and keeping them accountable to tasks and completion dates will help change the dynamic.

I’m a tech manager with a 100% remote team of seven employees. We’re a very high performing team overall, and I give minimal hand-holding while still fostering a collaborative working environment.

First off, you need to make outcomes clear. Assign tasks, and expect them to get done in a reasonable timeframe. But beyond that, there should be no reason to micro-manage actual working hours. If some developer needs some time during the day to run an errand and wants to catch up in the evening, fine by me. I don’t need them to be glued to their desk 9-5/10-6 or for some set part of the day — so long as the tasks are getting done in reasonable time, I let me employees structure their working hours as they see fit.

Three times a week we have regular whole-team checkins (MWF), where everyone can give a status update on their tasks. This helps keep up accountability.

Once a month I reserve an hour for each employee to just have a general sync-up. I allow the employee to guide how this time is used — whether they want to talk about issues with outstanding tasks, problems they’re encountering, their personal lives, or just “shoot the shit”. I generally keep these meetings light and employee-directed, and it gives me a chance to stay connected with them on both a social level and understand what challenges they might be facing.

And that’s it. I’ve actually gone as far as having certain employees who were being threatened with back-to-office mandates to have them converted to “remote employee” in the HR database so they’d have to lay off threatening them — only 2 of my 7 employees are even in the same general area of the globe (my employees are spread in 3 different countries at the moment), and I don’t live somewhere with an office, so having some employees forced to report to an office doesn’t help me in the slightest (I can’t be in 6 places at once — I live far enough away I can’t be in any of those places on a regular basis!).

Your employees may have got used to you micro-managing them. Changing this won’t happen overnight. Change from a micro-manager into a coach, and set them free. And if they fail…then it’s time to talk to HR and to see about making some changes. HTH!

That if a racoon saw you swimming, it would swim out to you and sit on your head and drown you.

My fully adult mother actually feared this was something that could happen to her children, and she warned us of this “danger” every summer when we were young.

I started back in the Wild West BBS days on the 80s; graduated to USENET in the 90s, website forums in the Web 1.0 days, /., Reddit, and now Lemmy. Yeah, I’ve been around. Been “Yaztromo” all that time too.

I don’t mind that “Eternal September” hasn’t infected this space yet — that’s a feature, not a bug!

I’m not sure what’s keeping Microsoft and ibm from Open Sourcing all the rest of the DOS versions as well — the 3.x series was very influential, 5 added disk compression, and 6 was the most modern of them all. I can’t remember if Stac’s lawsuit against Microsoft would require them to take out the disk compression parts (although AFAIK the relevant patents are probably long expired now), but even if that’s the case having these available as OSS would also be useful — even if only for a historical context.

To put things into context, IBM didn’t get ripped off in any way (at least not from DOS - the whole IBM/Microsoft OS/2 debacle is a different story). The earliest PCs (IBM PC, IBM PC XT, IBM PC Jr., and associated clones) didn’t really have the hardware capabilities needed to permit a more advanced operating system. There was no flat memory model, no protection rings, and no Translation Look-aside Buffer (TLB). The low maximum unpaged memory addressing limit (1MB) made it difficult to run more than one process at a time, and really limits how much OS you can have active on the machine (modern Windows by way of example reserves 1GB of virtual RAM per process just for kernel memory mapping).

These things did exist on mainframe and mini computers of the day — so the ideas and techniques weren’t unknown — but the cheaper IBM PCs had so many limitations that those techniques were mostly detrimental (there were some pre-emptive OSs for 8086/8088 based PCs, but they had a lot of limitations, particularly around memory management and protection), if not outright impossible. Hence the popularity of DOS in its day — it was simple, cheap, didn’t require a lot of resources, and mostly stayed out of the way of application development. It worked reasonably well given the limitations of the platforms it ran on, and the expectations of users.

So IBM did just fine from that deal — it was when they went in with Microsoft to replace DOS with a new OS that did feature pre-emptive multitasking, memory protection, and other modern techniques that they got royally screwed over by Microsoft (vis: the history of OS/2 development).

As someone who has done some OS dev, it’s not likely to be of much help. DOS didn’t have much of any of the defining features of most modern OS’s — it barely had a kernel, there was no multitasking, no memory management, no memory protection, no networking, and everything ran at the same privilege level. What little bit of an API was there was purely through a handful of software interrupts — otherwise, it was up to your code to communicate with nearly all the hardware directly (or to communicate with whatever bespoke device driver your hardware required).

This is great for anyone that wants to provide old-school DOS compatibility, and could be useful in the far future to aid in “digital archaeology” (i.e.: being able to run old 80’s and early 90’s software for research and archival purposes on “real DOS”) — but that’s about it. DOS wasn’t even all that modern for its time — we have much better tools to use and learn from for designing OS’s today.

As a sort of historical perspective this is useful, but not likely for anything else.

AWS already had to effectively do this. AWS only exists in two regions in China because they licensed much of the AWS software to be run by a pair of Chinese-government affiliated ISPs inside China (that is, Amazon doesn’t run AWS in either of its China zones — it’s run by a pair of Chinese companies who license AWS’s software).

This is why the China AWS regions are often quite far behind in terms of functionality from every other region (they either haven’t licensed all the functionality, they don’t keep up-to-date at the same cadence as Amazon, or Amazon is holding certain functions back), and why you can’t really access them from the standard AWS console.

So in effect, Amazon did have to give their software to Chinese-government affiliated companies in order to continue operating in China.

Likely well deserved — but still unfortunate. The EV space only benefits from more options and more competition.

An honest review isn’t what’s going to kill their business. Even a bad product in and of itself isn’t necessarily what could cause the death of their business — it’s their not adequately tempering consumer expectations. From the sounds of it, they’ve oversold what the product can actually do, and are charging a price based on this fantasy.

If you’re honest in your marketing as to what your product can actually do, and charge a corresponding price then consumers and reviewers may be more forgiving. Where companies like this one which are doing fairly experimental stuff fail is when they over-promise and under-deliver. And reviewers will always take them to task when they do that.

Image for a moment how we Computer Scientists feel. We invented the most brilliant tools humanity has ever conceived of, bringing the entire world to nearly anyone’s fingertips — and people use it to design and perpetuate pathetic brain-rot garbage like Gab.ai and anti-science conspiracy theories.

Fucking Eternal September…

Got a T-Mobile eSIM while travelling in the US last year to get around this. The eSIM was a great deal (can’t remember the specifics, but pretty cheap with a decent amount of data). I was making two trips to California and Georgia in the same 30 day window, so it was useful to have.

The only downside was that I couldn’t activate the eSIM before getting to the US, and LAX didn’t appear to have any WiFi while we were there (not sure if that was generally true for the time, or if it was just offline). So I wound up having to roam to get the eSIM, and to get a text message from the shuttle that was picking us up from the airport (as I had to give them that in advance, and didn’t know what my US number would be until I got there).

Still saved us some money, but it was a bit of a PITA to activate with no WiFi available at the airport.

First — stop giving them ideas! 🤣

Second, a small rock and some tape would likely defeat that.

EV charging doesn’t require you to stand around for 5 minutes holding a handle to fuel up. The charging times are longer, but once plugged in your need to stay anywhere near the vehicle is zero. And plugging in usually takes less than 5s.

So even if someone came up with a system whereby they expected you to watch an ad before the power would flow, you could always just plug in and walk away. How are they going to know you’re physically there?

As an EV driver I haven’t been to a gas station since I started driving it, but AFAIK this advertising hasn’t come to Canada — and hopefully it never does.

You can learn a ton installing your own OS, even if you don’t get things working in the end. Especially back in the 90’s when things weren’t quite as plug-and-play and hardware auto-detection was immature. So even if your RedHat experiment failed, good on you for attempting it anyway!

It was quite the interesting thing to run back then — it was all very “Wild West” of software, and a LOT of stuff didn’t work well.

It wasn’t my daily driver; it really wasn’t ready for most workloads back then. But it was nearly free, and we shared around the CD-ROM amongst hacker friends interested in giving it a try.