joushou

They all have wtf bugs. Think "JIT errors causing string concats to yield number objects and bitwise operators to fail when the code has run over 1000 times"-level wtf. I consider most of the "frontend" issues quite minor in that regard. Edge behaves very nicely, and for most intents and purposes. Older IE's were very much WTF: tickle it wrong - it could be as little as accessing the Math object at a bad time - and you got peculiar Access Denied exceptions (sometimes uncatchable, sometimes not), crashes, or other weird behaviour.

I agree on it mostly landing on ecosystem integration. I recently went from Safari to Chrome simply due to switching (back, after a few years away) to Android.

The only differences I feel after the switch is that Chrome's password integration is much quirkier than Safari's, and even quirkier when syncing to phone. Another difference is of course that the tab bar looks different, but that's basically it. Things sync to Google instead of to Apple. Maybe if I checked, I'd notice poorer battery life, but with battery life in the 7-10 hour range, I'm good.

Yeah, it probably has full-time 4WD with a viscous clutch at center - when you turn, your axles lock, and 3 out of 4 wheels will have to slip to let you get anywhere. This will cause jumping and tire noise. Engine torque won't change much.

LSD's front and rear makes this worse, but center is the most important when it comes to on-road maneuverability.

Audi Quattro is great, although IIRC, it also eats a bit tires on tight turns like anything but an open diff would. I also like the viscous clutch on the jeep, although it definitely is less on-road friendly (A tight 90 degree turn is enough to hear the tires, 180 and you can almost feel the car get lower). My worst system was my 98 explorer - it engages the clutch completely when front axle falls behind, waits a second, disengages to check if axle is still behind, if so, reengages... It's jumpy as hell when turning, and sucked no matter what. You could mod it for pure 2WD operation by switch, but stock was awful.

However, I don't think you should underestimate electric systems. I mean, I hate car software with a passion, but when they work, they actually have really good characteristics. Things like LSD's where the pump is electrically enabled give quite smooth transitions, and can simulate the response of both on and offroad mechanic systems. Response time is also nearly instant. If car computers weren't bloody black boxes (or at least leave only important things to the black box!), these systems often end up being much simpler than their purely mechanic black voodoo counterparts.

This definition is broken.

You have 4WD if you have 4 driven wheels (and unless you count the spare, that's all my wheels). Then, you can have a multitude of differential configurations on the 3 differentials (open, lsd, locker, diff-less viscous clutch, diff-less locker).

A Jeep WK uses a locking differential center, and electric engaging LSD's front and rear. By that article, the car is AWD on road, and sorta 4WD when off. The Jeep WJ is either controlled by a viscous clutch (Quadra-Drive), or has manually selectable 2WD, 4WD open ("AWD") and 4WD locked ("4WD") modes. A 98 Ford Explorer pulses an electric clutch to go between 2WD and 4WD locked. These cars all behave very differently both on and off road, and they don't fit well in the authors categories.

If you're buying or owning a car that drives all wheels, the only useful information is the diffs. Labels like "4x4", "4WD", "AWD", "Quadra-Trac", and "Quattro" mean nothing.

Most new 4WD's use open diffs with electrically controlled lockers or LSD's, as that gives the best combined on/offroad experience. Permanent LSD's/viscous clutches (Jeep WJ, for example) is a bit more responsive in surprise low-traction conditions, but it eats your tires when you make tight u-turns, as the turn will progressively engage a complete diff lock. Center lock without diff works like a regular 2WD until you lock, but remember that if you have ANY type of locker on ANY axle (not LSD), then engaging in high traction conditions might snap your axels in a very loud and explosive manner, even if you think you're driving straight.

That won't do anything when it comes to encrypted sends. ZFS supports disk encryption without a hitch.

I wouldn't recommend using LUKS, though - leave it to the built-in support.

To some extend, yes, it is 'bigoted'. Someone needs to stock shelves, and someone with a lower education from Eastern Europe might be more willing to do it. Hell, I wouldn't be surprised if the blue-collar workers all ended up with a job, paying tax, while the people with a degree ended up in perpetual job hunting, living partially off social services of various sorts.

What we need to avoid is that people end up living off social services, and it's very difficult to know who ends up having a job, who ends up climbing the ropes and making something big out of themselves, and who just ends up lying in the gutter on the street. You definitely cannot tell this solely by education or origin - you'll only know when it happens.

Which is a great thing, as we can then focus on what matters/we care about. Normal people are annoying, and tend to be demanding. :)

What's your definition of embedded? It's not embedded if you're running a full blown OS on a regular ARM chip.

Anyway, you could make a ramdisk, put things in it and put it in your path. I doubt that a linux box will survive a dead root without hardcore sysadm skills, but it should work on plan9. Initrd is not meant to stay behind after boot, though.

No, I was talking about WAN, not LAN. (Note that 9front's fork of drawterm is a lot faster than the normal version - a regular drawterm can be a bit slow)

I am not located in the US, but hopping borders in europe does not seem to be a problem. It's less of a problem than with X-forwarding or VNC.

As for regular fs mounts (note that a remote control session on plan9 is actually also just a regular fs mount), I mount things from the US every once in a while, and I am located in Sweden. It's obviously not fast due to very high latency and limited bandwidth, but it works just fine within those constraints.

But of course, if the RTT >1 second, then it will take >1 second for a keystroke to show up on screen in a remote control session. You cannot be resistant to this (mosh tries to guess how things would look if the keystrokes had gone through, which is a major hack, and not really an issue).

A thing I forgot to mention: this means that if you "cpu" into another host, you can run text based commands, but you can also start the browser, mothra, or even doom in the same window. There is no difference between telnet and x forwarding on plan9.

devdraw, which is more of an X equivalent than curses, but oh well.

Again, the vt terminal emulator is available if you want vim over ssh.

What you lose is VT escape sequences, a hack to try to make TUI's when there was no alternative. In Plan9, your terminal windows naturally transition to be fully fledged GUI's when needed.

Also note that there is vt (at least on 9front), a terminal emulator for plan9, if you really want to use such applications. There's ssh too, if you need it.

Yes. For remote control, drawterm (a client to "cpu" into a plan9 box from a non-plan9 box) can even make the GUI feel local over poor connections (except if you try to play doom or something).

The 9P protocol is designed to deal with arbitrary blocking, as synthetic filesystems commonly block reads until some data is present. There are also automatic reconnection proxies (aan), and when a mountpoint is entirely unresponsive (lost connectivity), you can just unmount it. The pending calls will all fail gracefully.

The abstraction works well. The main issue is when you lose access to your root device. Just like if you booted a Linux machine from NFS, the root disk connection must be stable (how do you unmount without being able to read the binary). All other mounts can be arbitrarily flakey.

It doesn't put more trust in the network than NBD or NFS does. You don't access your root filesystem over a 3G connection or a flakey VPN on any platform. But, if you mount a remote filesystem that isn't root, disconnecting isn't fatal, you just have to reconnect when the connection is back (aan can handle that).