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).

You are referring to "popups" (that is, if a site by itself opens a new window/tab, not if you open a link in a new tab).

MirageOS is a unikernel framework - not a general purpose OS.

You can label whatever group you find yourself in to be "us", and the rest as "them", but they're no different than you. You're just being selfish in valuing your life more than theirs.

This selfishness if of course natural for any human, but that does not make it better.

I have no one labelled as "my own", at least not in the nationalist/patriotic sense. My family and friends my go into that category if we really must, but that's it.

If you put a gun to my head, I'm certainly not going to care if you're my local baker or a North Korean soldier, just to name a random nation. Hell, I'll probably have sympathies for the soldier, as they are just doing what they were told, like any other soldier would. Getting angry at them would be pointless, although I'd of course do my best to fight for survival, and if I came out the winner, I would be upset that the life I had to take was not the life that was to blame.

For the baker, it would be hard to tell if the hand was forced, or if the idea of slaughter was of their own making.

It doesn't matter which army is battling me, whether it is Russian, Chinese or American. They will have no problem killing me, because that's their job, and there is war. Dancing on my grave would be difficult, because that would require retrieving my body.

I'm not saying that war is not necessary, but pretending that you're fighting zombies thirsting for nothing but your blood is idiotic. The soldiers you're fighting joined their army to protect their people. The people itself most likely just want to passively continue with their life, not understanding what the war is about, knowing nothing but the date of the first bomb. The people that started the war is sitting somewhere cozy, out of reach.

There is no "them" or "us". "They" are just people. They are rarely even people that we disagree with - they're innocent civilians that were unlucky and lived in what turned into a war zone, or soldiers that are simply following orders to protect what they consider their home. The decision is whether or not to take hundreds, thousands, or even millions of lives exactly like the one of the navy officer with the launch code embedded in his chest. Lives that had nothing to do with the conflict at all.

The "bad guys", the ones you might actually refer to as "them", are sitting somewhere comfortable, far out of reach of any of this. Their only interaction in this is that they pressed a button.

I understand this point of view, and this was also my usual approach. The reason I stopped was that the result was unmanageable systems. If you wanted to change something that you had configured on system level a year before, or even just wanted to replicate it, it became a major overhead. More creative modifications could also sometimes cause conflicts on larger upgrades.

So instead, I keep my systems small. I do not install anything I don't need, and do not touch something that is not necessary. On my laptop, I have 3 "full" applications, 15 convenience tools from homebrew (bash, git, nmap, ...) and 3 kernel extensions (including one of my own) installed. Nothing else that counts as a system-wide modification. Most of my servers are completely stock Alpine, Arch or Ubuntu systems, only running static binaries I provided.

All this saves me from dependency hell, and means that I do not need to hesitate to wipe a machine for whatever reason. It takes me 5 minutes to set a new one up, including my local own work environment.

There's a different between having control (which I have, including on my OS X machine), and actually practicing it.

Nano-bender can help https://ru.wikipedia.org/wiki/Benderama#/media/File:Futurama...

*If you're writing an EVIL application, that is.

As a developer, and occasionally of the kernel variant, I also prefer to keep the OS stock. It's convenient, and allows for very speedy reinstalls. It also makes my environment identical across operating systems.

Having control does not mean you have to change anything. Also, most developers are regular users.

The original comment was about circumventing a users measure to use a new git from homebrew by having the bad guy modify .bashrc. If the bad guy has that ability, he does not need an RCE. My argument being that using homebrew to install a nee git is fine. The counterarguments being "evil applications" and "evil .bashrc", ehich already means that you're executing the bad guys code.

Hah, and that might not even take that long at the current rate! But we still got a better terminal emulator by default over here! Terminal.app is a pretty darn good terminal emulator, although iTerm2.app is better. That is actually one of the things I like about OS X - I have not found a terminal emulator for Linux (and certainly not for Windows) that compares with iTerm2. Not in speed, nor in interface.

BTW, for the curious, I just realized that you can easily disable the bundled git on OS X:

sudo chmod a-x /Applications/Xcode.app/Developer/usr/bin/git

Done. Running /usr/bin/git will now proxy you a permission denied error.

This seems to be a recurring topic: If you're writing an application, why bother hardcoding a path to a git version with a known RCE? You're already running on the machine.

Hell, if you want to hide your fault, bundle a random tool or lib that you know have an issue and exploit that. It'll be much more stable than relying on a local binary.

man xcode-select - It's right there in the manpage.

/usr/bin/git is a "toolshim" that effectively calls "xcrun git" (it actually calls xcselect_invoke_xcrun, from /usr/lib/libxcselect.dylib, if you really want the details - this can be found by inspecting the binary). xcode-select's manpage tells you that these shims call the respective binary in the active developer directory, whereas xcrun's manpage describes its capabilities in more detail.

It took about 3 minutes to figure out.