![](https://lemmy.today/pictrs/image/817e51c0-c1be-4c74-8884-fd73d6631b2b.png)
![](https://fry.gs/pictrs/image/c6832070-8625-4688-b9e5-5d519541e092.png)
What if it is and it became unrecoverable ages ago?
What if it is and it became unrecoverable ages ago?
Yeah, that’s another thing that bugs me about products that can be remotely-updated and especially those which don’t currently represent an ongoing revenue stream. I think that it’s a broader problem, too, not just cars.
I was kind of not enthusiastic when I discovered that TenCent bought the video game Oxygen Not Included and started pushing data-harvesting updates into it via Steam. As things stand, that’s optional. But any company could do the same with other games and not have it be optional. If you figure that all the games out there that have already been sold aren’t actually generating revenue but do represent the option to push and execute code on someone’s computer, they have value to some other company that could purchase them and monetize that.
Then you figure that the same applies to browser extensions.
And apps on phones.
And all those Internet of Things devices that can talk to the network, cameras and microphones and all sorts of stuff.
There’s a lot of room for people to sit down and say “what I have is a hook into someone else’s stuff…now what things might I do to further monetize that? Or who might I sell that hook to who might be interested in doing that?”
Like, if I buy a product, all I can do when I make my purchasing decision is to evaluate the product as it is at purchase time. If the vendor also has the ability and right to change that product whenever they want, then what I’m actually buying is a pretty big question mark. And unless they’ve got some kind of other revenue stream on the line, their only real incentive to avoid doing so is the reputational hit they take…which for failing brands or companies, may not be all that large.
One constraint for efficient markets is that the consumers in it need to be informed as to what they’re buying. If they don’t have that property, you can get market failure. And a consumer can’t be informed about what he’s buying if the person selling them the product can change that product at any point after purchase.
From top-to-bottom:
Skynet from The Terminator
Joshua from WarGames
They are, however, able to inaccurately summarize it in GLaDOS’s voice, which is a strong point in their favor.
to ensure that the technology is “safe, secure and trustworthy.”
None of the really iconic AIs are safe, secure or trustworthy.
That would reduce fuel usage.
I bet that those ad guys haven’t even considered or promoted the fact that they can reduce carbon emissions.
Clearly, the problem is that they went with a pure subscription model instead of also having an ad-supported model. Like, supposing that you’re allowed to turn on the seat heater, but then the car starts playing advertisements while it’s running. They could offer a premium seat heater subscription if you want to buy an ad-free experience.
shakes head sorrowfully
They aren’t very innovative.
https://en.wikipedia.org/wiki/Monty_Python
The group came to prominence for the sketch comedy series Monty Python’s Flying Circus, which aired on the BBC from 1969 to 1974.
No, I believe that that was paid for by the television tax in the UK, rather than interspersed advertisements, as probably most television is.
See, they’re probably just framing it in negative terms. Just has to be presented in the right way.
https://www.telenav.com/blog/why-in-car-advertising-works
Why In-Car Advertising Works
For over two decades, advertising has fueled the online and mobile world. What can it do for your car?
Advertising is worth it to the consumer.
In-car ads are a win-win for drivers and automakers.
In-car ads can also be rather helpful while on the drive.
As a matter of fact, a recent McKinsey Report [Monetizing Car Data, McKinsey & Company September 2016] indicates that most consumers would prefer ads for connected navigation service.
The way to think of it isn’t “ads come up whenever my car stops”, but “ads go away whenever it starts moving!”
Drivers will never see an ad while their vehicles are in motion. Ads automatically disappear whenever the car is moving or when users interact with other in-dash functions. For example, when a driver starts her vehicle, a relevant ad will appear on her dashboard. The moment the driver shifts into reverse to back out the driveway, the ad automatically disappears.
This isn’t a new thing because even my decade old Toyota car with the SirusXM car radio automatically switches to the XM 1 radio station that advertises the SirusXM subscription service about once a month ever since I cancelled the subscription a year after the original three month one expired. Fuck that company and their monthly resubscribtion demand letters also!
Hmm. I think that this is maybe kind of a fundamental problem with buying something that you want to keep with attached hardware from a company with a subscription service that you don’t want.
Ah, just on the screen. If they had those HUD windshield projectors, they could put them on the windshield too. I mean, that’s pretty much just unused eyeball space!
EDIT: The car has an audio system too, and here, the ad-displaying system also controls the audio, so this muting nonsense that one runs into with web browser ads isn’t a problem! They could have ads with an audio component!
If Justin Trudeau gets active on this, you can probably get it to Gulf of Canada (Gulf of Mexico) (Gulf of America).
Wouldnt the sync option also confirm that every write also arrived on the disk?
If you’re mounting with the NFS sync option, that’ll avoid the “wait until close and probably reorder writes at the NFS layer” issue I mentioned, so that’d address one of the two issues, and the one that’s specific to NFS.
That’ll force each write to go, in order, to the NFS server, which I’d expect would avoid problems with the network connection being lost while flushing deferred writes. I don’t think that it actually forces it to nonvolatile storage on the server at that time, so if the server loses power, that could still be an issue, but that’s the same problem one would get when running with a local filesystem image with the “less-safe” options for qemu and the client machine loses power.
That’s designed to work at 120V. The PSU-GPU connector is 12V. I don’t know if it’d actually work well – like, the contacts would have a tenth the conductive capacity, I guess.
Honestly, the main standardized 12V DC connector that I can think of that we use is the car cigarette lighter, which I don’t think normally moves anything like that much power and is terrible, doesn’t lock into place, was never intended as a power source. I would like a 12V locking connector that can move a lot of juice.
https://www.amazon.com/JacobsParts-Cigarette-Lighter-Adapter-Electronics/dp/B012UV3QI4
Input Voltage: 12 Volts
Amperage: 2 Amps
That particular cable and plug will handle 24 watts. I know that you can get higher power ones – I had to go out of my way to find one that could do 100W.
My guess is that the 12V problem will never really be addressed and we’ll just go to USB-C PD at up to 50.9V for our DC power connector standard. Which I guess works too as long as the amperage doesn’t get too high, but that won’t be enough to feed a current high-end Nvidia GPU.
Maybe have, like, multiple USB-C PD connectors in parallel. Three should do it.
NFS doesn’t do snapshotting, which is what I assumed that you meant and I’d guess ShortN0te also assumed.
If you’re talking about qcow2 snapshots, that happens at the qcow2 level. NFS doesn’t have any idea that qemu is doing a snapshot operation.
On a related note: if you are invoking a VM using a filesystem images stored on an NFS mount, I would be careful, unless you are absolutely certain that this is safe for the version of NFS and the specific caching options for both NFS and qemu that you are using.
I’ve tried to take a quick look. There’s a large stack involved, and I’m only looking at it quickly.
To avoid data loss via power loss, filesystems – and thus the filesystem images backing VMs using filesystems – require write ordering to be maintained. That is, they need to have the ability to do a write and have it go to actual, nonvolatile storage prior to any subsequent writes.
At a hard disk protocol level, like for SCSI, there are BARRIER operations. These don’t force something to disk immediately, but they do guarantee that all writes prior to the BARRIER are on nonvolatile storage prior to writes subsequent to it.
I don’t believe that Linux has any userspace way for an process to request a write barrier. There is not an fwritebarrier()
call. This means that the only way to impose write ordering is to call fsync()/sync() or use similar-such operations. These force data to nonvolatile storage, and do not return until it is there. The downside is that this is slow. Programs that are frequently doing such synchronizations cannot issue writes very quickly, and are very sensitive to latency to their nonvolatile storage.
From the qemu(1)
man page:
By default, the cache.writeback=on mode is used. It will report data writes as completed as soon as the data is present in the host page cache. This is safe as long as your guest OS makes sure to correctly flush disk caches where needed. If your guest OS does not handle volatile disk write caches correctly and your host crashes or loses power, then the guest may experience data corruption. For such guests, you should consider using cache.writeback=off. This means that the host page cache will be used to read and write data, but write notification will be sent to the guest only after QEMU has made sure to flush each write to the disk. Be aware that this has a major impact on performance.
I’m fairly sure that this is a rather larger red flag than it might appear, if one simply assumes that Linux must be doing things “correctly”.
Linux doesn’t guarantee that a write to position A goes to disk prior to a write to position B. That means that if your machine crashes or loses power, with the default settings, even for drive images sorted on a filesystem on a local host, with default you can potentially corrupt a filesystem image.
https://docs.kernel.org/block/blk-mq.html
Note
Neither the block layer nor the device protocols guarantee the order of completion of requests. This must be handled by higher layers, like the filesystem.
POSIX does not guarantee that write() operations to different locations in a file are ordered.
https://stackoverflow.com/questions/7463925/guarantees-of-order-of-the-operations-on-file
So by default – which is what you might be doing, wittingly or unwittingly – if you’re using a disk image on a filesystem, qemu
simply doesn’t care about write ordering to nonvolatile storage. It does writes. it does not care about the order in which they hit the disk. It is not calling fsync()
or using analogous functionality (like O_DIRECT
).
NFS entering the picture complicates this further.
https://www.man7.org/linux/man-pages/man5/nfs.5.html
The sync mount option The NFS client treats the sync mount option differently than some other file systems (refer to mount(8) for a description of the generic sync and async mount options). If neither sync nor async is specified (or if the async option is specified), the NFS client delays sending application writes to the server until any of these events occur:
Memory pressure forces reclamation of system memory resources. An application flushes file data explicitly with sync(2), msync(2), or fsync(3). An application closes a file with close(2). The file is locked/unlocked via fcntl(2). In other words, under normal circumstances, data written by an application may not immediately appear on the server that hosts the file. If the sync option is specified on a mount point, any system call that writes data to files on that mount point causes that data to be flushed to the server before the system call returns control to user space. This provides greater data cache coherence among clients, but at a significant performance cost. Applications can use the O_SYNC open flag to force application writes to individual files to go to the server immediately without the use of the sync mount option.
So, strictly-speaking, this doesn’t make any guarantees about what NFS does. It says that it’s fine for the NFS client to send nothing to the server at all on write(). The only time a write() to a file makes it to the server, if you’re using the default NFS mount options. If it’s not going to the server, it definitely cannot be flushed to nonvolatile storage.
Now, I don’t know this for a fact – would have to go digging around in the NFS client you’re using. But it would be compatible with the guarantees listed, and I’d guess that probably, the NFS client isn’t keeping a log of all the write()s and then replaying them in order. If it did so, for it to meaningfully affect what’s on nonvolatile storage, the NFS server would have to fsync() the file after each write being flushed to nonvolatile storage. Instead, it’s probably just keeping a list of dirty data in the file, and then flushing it to the NFS server at close().
That is, say you have a program that opens a file filled with all ‘0’ characters, and does:
At close() time, the NFS client probably doesn’t flush “1” to position 1, then “1” to position 5000, then “2” to position 1, then “2” to position 5000. It’s probably just flushing “2” to position 1, and then “2” to position 5000, because when you close the file, that’s what’s in the list of dirty data in the file.
The thing is that unless the NFS client retains a log of all those write operations, there’s no way to send the writes to the server in a way that avoid putting the file into a corrupt state if power is lost. It doesn’t matter whether it writes the “2” at position 1 or the “2” at position 5000. In either case, it’s creating a situation where, for a moment, one of those two positions has a “0”, and the other has a “2”. If there’s a failure at that point – the server loses power, the network connection is severed – that’s the state in which the file winds up in. That’s a state that is inconsistent, should never have arisen. And if the file is a filesystem image, then the filesystem might be corrupt.
So I’d guess that at both of those two points in the stack – the NFS client writing data to the server, and the server block device scheduler, permit inconsistent state if there’s no fsync()/sync()/etc being issued, which appears to be the default behavior for qemu
. And running on NFS probably creates a larger window for a failure to induce corruption.
It’s possible that using qemu’s iSCSI backend avoids this issue, assuming that the iSCSI target avoids reordering. That’d avoid qemu going through the NFS layer.
I’m not going to dig further into this at the moment. I might be incorrect. But I felt that I should at least mention it, since filesystem images on NFS sounded a bit worrying.
Honestly, I’m a little surprised that a smartphone user wouldn’t have familiarity with the concept of files, setting aside the whole familiarity-with-a-PC thing. Like, I’ve always had a file manager on my Android smartphone. I mean, ok…most software packages don’t require having one browse the file structure on the thing. And many are isolated, don’t have permission to touch shared files. Probably a good thing to sandbox apps, helps reduce the impact of malware.
But…I mean, even sandboxed apps can provide file access to the application-private directory on Android. I guess they just mostly don’t, if the idea is that they should only be looking at files in application-private storage on-device, or if they’re just the front end to a cloud service.
Hmm. I mean, I have GNU/Linux software running in Termux, do stuff like scp
from there. A file manager. Open local video files in mpv
or in PDF viewers and such. I’ve a Markdown editor that permits browsing the filesystem. Ditto for an org-mode editor. I’ve a music player that can browse the filesystem. I’ve got a directory hierarchy that I’ve created, though simpler and I don’t touch it as much as on the PC.
But, I suppose that maybe most apps just don’t expose it in their UI. I could see a typical Android user just never using any of the above software. Not having a local PDF viewer or video player seems odd, but I guess someone could just rely wholly on streaming services for video and always open PDFs off the network. I’m not sure that the official YouTube app lets one actually save video files for offline viewing, come to think of it.
I remember being absolutely shocked when trying to view a locally-stored HTML file once that Android-based web browsers apparently didn’t permit opening local HTML files, that one had to set up a local webserver (though that may have something to do with the fact that I believe that by default, with Web browser security models, a webpage loaded via the file://
URI scheme has general access to your local filesystem but one talking to a webserver on localhost does not…maybe that was the rationale).
There was something of an earlier effort to do MOOCs. My impression is that they didn’t take off, because I stopped hearing about them. But I don’t really follow current education, so…
I think that at some point, dramatic improvements to education are probably doable, and that we probably have the technology today.
But I’m kind of skeptical that AI is really the missing piece, at least given the state that it’s in today.
The text you wanted. Searched using what text was visible in your image in Google to find the original URL, which you didn’t include, then grabbed the original text, courtesy of archive.org’s Wayback Machine:
what does the grub2 boot line look like?
/boot is traditionally a separate partition, although it may not be required depending on how new your hardware is.
/boot/EFI must be its own partition and formatted vfat file system in EFI boot systems.
There’s an xkcd for that:
Don’t they support video posts?
kagis
Hmm. Apparently so.
https://help.tumblr.com/knowledge-base/posting-video/
Well, it’s not an open platform, but I guess it may be a platform with the resources to serve some serious video, and it’ll be on the Fediverse.
We have been having a lot of discussions about what it would take to get video on the Fediverse at more than PeerTube scale.
I don’t use tumblr, don’t know if they provide a video-centric interface, but I imagine that one could always write a software package to index those videos and link to them. Maybe PeerTube can already do that, haven’t played with it enough to know.