This is true for bricks, but it is not true if your dog starts up your car and hits a pedestrian. Collisions caused by non-human drivers are a fascinating edge case for the times we're in.
It is very much true for dogs in that case: (1) it is your dog (2) it is your car (3) it is your responsibility to make sure your car can not be started by your dog (4) the pedestrian has a reasonable expectation that a vehicle that is parked without a person in it has been made safe to the point that it will not suddenly start to move without an operator in it and dogs don't qualify.
what if your car was parked in a normal way that a reasonable person would not expect to be able to be started by a dog, but the dog did several things that no reasonable person would expect and started it anyway?
You can 'what if' this until the cows come home but you are responsible, period.
I don't know what kind of drivers education you get where you live but where I live and have lived one of the basic bits is that you know how to park and lock your vehicle safely and that includes removing the ignition key (assuming your car has one) and setting the parking brake. You aim the wheels at the kerb (if there is one) when you're on an incline. And if you're in a stick shift you set the gear to neutral (in some countries they will teach you to set the gear to 1st or reverse, for various reasons).
We also have road worthiness assessments that ensure that all these systems work as advertised. You could let a pack of dogs loose in my car in any external circumstance and they would not be able to move it, though I'd hate to clean up the interior afterwards.
I agree. The dog smashed the window, hot–wired the ignition, released the parking brake, shifted to drive, and turned the wheel towards the opposite side of the road where a mother was pushing a stroller, killing the baby. I know, crazy right, but I swear I'm not lying, the neighbor caught it on camera.
Who's liable?
I think this would be a freak accident. Nobody would be liable.
You would not be guilty of a crime, because that requires intent.
But you would be liable for civil damages, because that does not. There are multiple theories for which to establish liability, but most likely this would be treated as negligence.
Well at that point we might as well say it's gremlins that you summoned, so who knows, there are no laws about gremlins hot-wiring cars. If you summoned them, are they _your_ gremlins, or do they have their own agency. How guilty are you, really... At some point it becomes a bit silly to go into what-if scenarios, it helps to look at exact cases.
> I agree. The dog smashed the window, hot–wired the ignition,
> released the parking brake, shifted to drive, and turned the
> wheel towards the opposite side of the road where a mother was
> pushing a stroller, killing the baby. I know, crazy right, but
> I swear I'm not lying, the neighbor caught it on camera.
> Who's liable?
You are. It's still your dog. If you would replace dog with child the case would be identical (but more plausible). This is really not as interesting as you think it is. The fact that you have a sentient dog is going to be laughed out of court and your neighbor will be in the docket together with you for attempting to mislead the court with your AI generated footage. See, two can play at that.
When you make such ridiculously contrived examples turnaround is fair play.
What if you have an email in your inbox warning you that 1) this specific bush attracts bats and 2) there were in fact bats seen near you bush and 3) bats were observed almost biting a child before. And you also have "how do I fuck up them kids by planting a bush that attracts bats" in your browser history. It's a spectrum you know.
Well, if it was a bush known to also attract children, it was on your property, and the child was in fact attracted by it and also on your property, and the presence of the bush created the danger of bat bites, the principal of “attractive nuisance” is in play.
With all due respect, that's all the more reason to put all the resources they can behind browser development, rather than scattering it across unrelated projects.
That's a funny example. I have no issues with the idea of course but in my day to day life I'm way more likely to encounter an issue with colors being lost after sent to a pager or a log file or tee or what not
There are infinite things worth doing, a machines ability to actually know what's worth doing in any given scenario is likely on par with a human's. What's "Worth doing" is subjective, everything comes down to situational context. Machines cannot escape the same ambiguity as humans. If context is constant, then I would assume overlapping performance on a pretty standard distribution between humans and machines.
Machines lower the marginal cost of performing a cognitive task for humans, it can be extremely useful and high leverage to off load certain decisions to machines. I think it's reasonable to ask a machine to decide when machine context is higher and outcome is de-risked.
Human leverage of AGI comes down to good judgement, but that too is not uniformly applied.
For what human leverage of AGI may look like, look at the relationship between a mother and a toddler.
As you said: There's an infinite number of things a toddler may find worth doing, and they offload most of the execution to the mother. The mother doesn't escape the ambiguity, but has more experience and context.
Of course, this all assumes AGI is coming and super intelligent.
Well, because people are lazy. They already ask it for advice and it gives answers that they like. I already see teams using AI to put together development plans.
If you assume super intelligence, Why wouldn't that expand? Especially when it comes to competitive decisions that have a real cost when they're suboptimal?
The end state is that agents will do almost all of the real decision making, assuming things work out as the AI proponents say.
It's not the syscalls. There were only 300,000 syscalls made. Entering and exiting the kernel takes 150 cycles on my (rather beefy) Ryzen machine, or about 50ns per call.
Even assume it takes 1us per mode switch, which would be insane, you'd be looking at 0.3s out of the 17s for syscall overhead.
It's not obvious to me where the overhead is, but random seeks are still expensive, even on SSDs.
I'm sympathetic to that argument, but to invoke it you have to argue why the anti-fraud measures outweigh the benefits, not just drop a link to it. Moreover that's giving too much credit to the OP, who doesn't even recognize there's some sort of a trade-off, only that "fool and their money is soon departed".
Imagine a race condition that writes a file node where a directory node should be. You have a valid object with a valid checksum, but it's hooked into the wrong place in your data structure.
> Imagine a race condition that writes a file node where a directory node should be. You have a valid object with a valid checksum, but it's hooked into the wrong place in your data structure.
A few things: 1) Is this an actual ZFS issue you encountered or is this a hypothetical? 2) And -- you don't imagine this would be discovered during a scrub? Why not? 3) But -- you do imagine it would be discovered and repaired by an fsck instead? Why so? 4) If so, wouldn't this just be a bug, like a fsck, not some fundamental limitation of the system?
FWIW I've never seen anything like this. I have seen Linux plus a flaky ALPM implementation drop reads and writes. I have seen ZFS notice at the very same moment when the power dropped via errors in `zpool status`. I do wonder if ext4's fsck or XFS's fsck does the same when someone who didn't know any better (like me!) sets the power management policy to "min_power" or "med_power_with_dipm".
Here's an example: https://www.illumos.org/issues/17734. But it would not be discovered by a scrub because the hashes are valid. Scrubs check hashes, not structure. It would be discovered by a fsck because the structure is invalid. Fscks check structure, not hashes.
They are two different tools, with two different uses.
How is the structure not valid here? Can you explain to us how an fsck would discover this bug (show an example where an fsck fixed a similar bug) but ZFS could never? The point I take contention with is that missing an fsck is a problem for ZFS, so more specifically can you answer my 4th Q:
>> 4) If so, wouldn't this just be a bug, like (a bug in) fsck, not some fundamental limitation of the system?
So -- is it possible an fsck might discover an inconsistency ZFS couldn't? Sure. Would this be a fundamental flaw of ZFS, which requires an fsck, instead of merely a bug? I'm less sure.
You do seem to at least understand my general contention with the parent's point. However, the parent is also making a specific claim about a bug which would be extraordinary. Parent's claim is this is a bug which a scrub, which is just a read, wouldn't see, but a subsequent read would reveal.
So -- is it possible an fsck might discover this specific kind of extraordinary bug in ZFS, after a scrub had already read back the data? Of that I'm highly dubious.
> Can you show us how an fsck would discover this bug but ZFS could never?
I'd have to read closer to be certain, but if my understanding of it is correct, you'd have orphaned objects in the file system. The orphaned objects would be detectable, but would have correct hashes.
> if so, wouldn't this just be a bug, like (a bug in) fsck, not some fundamental limitation of the system?
It's not a bug or a fundamental limitation of the system, it's just that fsck != scrub, and nobody has written the code for fsck. If someone wanted to write the code, they could. I suspect it wouldn't even be particularly hard.
But fsck != scrub, and they catch different things.
Typically, if you were writing your hypothetical sql client in rc shell, you'd implement an interface that looks something like:
<>/mnt/sql/clone{
echo 'SELECT * from ...' >[1=0]
cat /mnt/sql/^`{read}^/data # or awk, or whatever
}
This is also roughly how webfs works. Making network connections from the shell follows the same pattern. So, for that matter, does making network connections from C, just the file descriptor management is in C.
This is... I don't know. I don't get why I would care to sling SQL over a file system versus a network socket.
I mean, Postgres could offer an SSH interface as a dumb pipe to psql to just have you push text SQL queries in your application. But it doesn't, it offers a binary protocol over a network socket. All the database engines have had the same decision point and have basically gone down the same path of implementing a wire protocol over a persistent socket connection.
So yeah, I don't get what doing things this way would give me as either a service provider or a service consumer. It looks like video game achievements for OS development nerds, "unlocked 'everything is a file'." But it doesn't look like it actually enables anything meaningful.
But if it requires understanding of a data protocol, it doesn't really matter if it's over the file system or a socket or flock of coked-up carrier pigeons. You still need to write custom user space code somewhere. Exposing it over the file system doesn't magically make composable applications, it just shuffles the code around a bit.
In other words, the transport protocol is just not the hard part of anything.
It's not hard, but it's sure a huge portion of the repeated boilerplate glue. Additionally, the data protocols are also fairly standardized in Plan 9; The typical format is tabular plain text with '%q'-verb quoting.
There's a reason that the 9front implementation of things usually ends up at about 10% the size of the upstream.
The benefit is that you can allocate arbitrary computers to compute arbitrary things. As it is now, you have to use kubernetes and it's a comedy. Though perhaps the same in effect, there are dozens of layers of abstraction that will forever sting you.
You're thinking from the perspective of the terminal user—ie, a drooling, barely-conscious human trying to grasp syntax and legal oddities of long-dead humans. Instead you need to think from the perspective of a star trek captain. Presumably they aren't manually slinging sql queries. Such tasks are best automated. We are all the drooling terminal user in the end, but plan9 enabled you to at least pretend to be competent.
I’ve been on/off playing with 9front on an old laptop. I’ve been having a lot of fun with it, it’s fun to write code for, but i have had a hard time using it as anything but a toy.
I would love to use it as my main desktop, but ultimately (and kind of unsurprisingly), the blocker is the lack of a modern browser and a lack of video acceleration.
I’m sure I could hobble something together with virtualization for the former but I don’t see a fix for video acceleration coming.
Maybe I could install it on a server or something.
I did the same with an old Thinkpad but somehow found it relies too heavily on the mouse. I might still go back to it because I love how far they've taken the "everything is a file" idea and would like to experiment more with that.
I saw on HN in a different Plan 9 thread (though I'm having a bit of trouble finding it), where someone mentioned the idea of using Plan 9 to build a custom router.
I have a very rough mental model of how that could be done, and I think it would be cool to say I have that, but I haven't been bothered to replace my beloved NixOS router yet.
Same here. I made a custom router (debian, nftables, dnsmasq, etc and python code to manage it all over ssh) and I spent way too much time on it to replace it :-)
reply