How would you implement things like version history or shareable URLs to files without a database?
Another issue would be permissions: if I wanted to restrict access to a file to a subset of users, I’d have to make a group for that subset. Linux supports a maximum of 65536 groups, which could quickly be exhausted for a nontrivial number of users.
There is no support for writing multiple xattrs in one transaction.
There is no support for writing multiple xattrs and file contents in one transaction.
Journaled filesystems that immediately flush xattrs to the journal do have atomic writes of single xattrs; so you'd need to stuff all data in one xattr value and serialize/deserialize (with e.g JSON, or potentially Arrow IPC with Feather ~mmap'd from xattrs (edit: but getxattr() doesn't support mmap. And xattr storage limits: EXT4: 4K, XFS: 64k, BTRFS: 16K)
Well sure there’s a bevy of features you’re missing out on, but it would work. Object store and file metadata solves both of those though feels like cheating.
> Filesystem or LVM snapshots immediately come to mind
I use ZFS snapshots and like them a lot for many reasons. But I don’t have any way to quickly see individual versions of a file without having to wade through a lot of snapshots where the file is the same because snapshots are at filesystem level (or more specifically in ZFS, at “dataset” level which is somewhat like a partition).
And also, because I snapshot at set intervals, there might be a version of a file that I wanted to go back to but which I don’t have a snapshot of at that exact moment. So I only have history of what the file was a bit earlier or a bit later than some specific moment.
I used to have snapshots automatically trigger every 2 minutes and snapshot clean up automatically trigger hourly, daily, weekly and monthly. In that setup it was fairly high chance that if I make some mistake with an edit to a file I also had a version of it that kept the edits from right before as long as I discover the mistake right away.
These days I snapshot automatically a couple of times per day and cleanup every few months with a few keystrokes. Mainly because at the moment the files I store on the servers don’t need that fine-grained snapshots.
Anyway, the point is that even if you snapshot frequently it’s not going to be particularly ergonomic to find the version you want. So maybe the “Google Drive” UI would also have to check each revision to see if they were actually modified and only show those that were. And even then it might not be the greatest experience.
If you are on windows with a Samba share hooked up to zfs you can actually use the "previous versions" in file explorer for a given folder and your snapshots will show up :) there are some guides online on setting it up
>Nobody has ever walked past a photograph because they can't inspect its digital authenticity hash.
This has rapidly changed over the last few months. As more and more pictures/videos going viral on social media are AI-generated [0, 1], real pictures/videos of remarkable things are increasingly falsely called out as AI-generated [2]. People are definitely starting to care, and while the toy camera in the linked article is merely an artistic statement, having some ubiquitously standardized way of unambiguously validating content generated by a real recording device is going to become paramount.
How much of this is due to a high level of pre-purchase excitement followed by buyer's remorse? Anecdotally, I know several people who were gung ho about getting an EV, fully willing to pay its cost premium, who initially loved their EVs but sold them within a year or two after encountering issues that only become apparent with semi-long-term ownership:
— In the US, charging infrastructure is still quite poor, with a high amount of disabled or damaged chargers that aren't apparent on maps. Nothing worse than planning a route around the only charger within a few dozen miles and arriving to find it broken. The overall overhead of having to plan driving/parking around chargers is also too onerous for some people.
— Similarly, people underestimate how much harder long road trips are on EVs, especially when fast chargers are damaged and don't actually supply anywhere close to the advertised amount of current.
— People underestimate how much range degrades in cold weather. One person I know bought their EV in the spring, loved it until winter came around, and then promptly sold it the next spring. In a similar vein, people don't realize how poor and battery-hungry climate control can be in an EV, especially in models without a heat pump.
It would be interesting to rigorously study this, examining whether people buying EVs are more likely to sell them within the first couple years of ownership versus people buying comparably priced ICE cars.
From personal experience over ~6 years of EV roadtrips, the first two really aren't much of a problem with a Tesla or a vehicle that can access Tesla's network.
Other chargers can definitely be a bit more hit-and-miss although they are improving.
These days if you stick to the big networks (Tesla, Electrify America, Rivian, IONNA, etc.) you're going to have a pretty good time. The one-off chargers in municipal parking garages are a different story, I don't really on those unless there is a recent PlugShare review showing that it actually works.
I agree that Tesla's network is universally pretty reliable. For the other networks, I've found it can be quite location-dependent, likely proportional to the density of EV drivers. Bay Area or LA? Pretty solid. Orlando? Not so much.
Now that basically every car can access Tesla Superchargers and vice versa for Teslas, this is really not a problem anymore. We’re at the « sometimes I’m grumpy the best stop for my car does not have the exact amenities
I want » stage now.
I guess is worse than the « the stop with the exact amnenities I want is not the provider with the cheapest electricity that I wanted » stage that we are in say, France.
Oh for- who the fuck is putting resistive heating in an EV?! What brain-dead PM greenlit that pants-on-head jackassery? Was it GM? I can see an American OEM getting that close to the goal line only to snatch defeat from the jaws of victory.
Really though, that's just disappointing; I had earnestly assumed every EV that made it to market (in North America at least) would be using a heat pump.
Tesla, Honda, Nissan, Chevy, Fiat and Volkswagen have all produced cars with resistive heat in the past decade (not an exhaustive list, just a list that I could find on the first page of search results). So no, not an exclusively American thing.
Heat pumps are expensive, complex, prone to warranty claims, and subject to additional regulatory control (refrigerants). Resistive heating is cheap and simple.
I'm guessing that the development costs for a heat pump that is good enough for automotive use is well into 8 figures, and would probably take at least a year to fully test.
Given all those constraints, it makes a tremendous amount of sense that many cars were built with resistive heating.
I'm not going to say they're ubiquitous in the automotive world (assuming non-belt-driven like you mention below), but they're hardly brand new. The battery-electric buses in my city have heat pumps, and (IIRC) other cities opted for air conditioning in their trolley-bus fleet over a decade ago. Built to automotive standards is hardly uncharted waters.
Though perhaps I'm simply blown away living in a colder climate. Resistive heating if it's only to defog windows in the morning, or similarly rarely used, is reasonable. Resistive when getting started (one major hurdle, ICE -> EV, resistive -> heat pump, at a time) is reasonable. I just thought the automotive world had moved forward more rapidly than it had.
heat pumps are not magical technology. Pretty much every car sold in the West in the last three decades has one. There is only one reversing valve worth of difference between a standard auto AC and a heat pump.
A belt driven AC powered by a combustion engine is not at all the same thing as a DC electric heat pump system.
Yes they both use compressors and refrigerant, but essentially none of the expensive and hard to engineer parts are interchangeable.
If that was true you could just replace your broken fridge with a car AC system, or for that matter just use a fridge to heat your house. After all they all use the same “not magical” technology.
As it turns out the underlying concept/technology is pretty simple, but adapting it to be fit for purpose is where the complexity lies.
If it was that easy the car companies would have done it instead of designing a novel resistive heating system that can only be used in their lowest volume cars.
Don't nearly all of these EVs already have DC-powered air conditioning though? Adding heat to an air conditioner is trivial. Where I live, they literally do not sell air conditioners without heat anymore.
The real world evidence is that many manufacturers came to the conclusion that designing an entire separate system for resistive heat was a better solution than the obvious step of reversing the cycle on the AC.
Heat pumps aren't free to run, they still require a decent amount of energy and and on shorter trips resistive heating (which is required for other reasons anyway) is quicker.
The one issue with this approach is that it would still traverse all hidden folders, which could be expensive (e.g. in a git repo with an enormous revision history in `.git/`). `-not -path ...` just prevents entities from being printed, not being traversed. To actually prevent traversal, you need to use `-prune`.
Depends on how big the directory is. If it only contains a few files, I'd just enumerate them all with `find`, filter the results with `grep`, and perform the actual `grep` for "bar" using `xargs`:
find . -type f -name "*.foo" | grep -v '/\.' | xargs grep bar
(This one I could do from muscle memory.)
If traversing those hidden files/directories were expensive, I'd tell `find` itself to exclude them. This also lets me switch `xargs` for `find`'s own `-exec` functionality:
find . -path '*/\.*' -prune -o -type f -name "*.foo" -exec grep bar {} +
Thanks yeah this is a good example of why I prefer the simpler interface for `rg` and `fd`. Those examples would actually be fine if this were something only did once in awhile (or in a script). But I search from the command line many times per day when I'm working, so I prefer a more streamlined interface.
For the record, I think `git grep` is probably the best builtin solution to the problem I gave, but personally I don't know off-hand how to only search for files matching a glob and to use the current directory rather than the repository root with `git grep` (both of which are must haves for me). I'd also need to learn those same commands for different source control systems besides git (I use one other VCS regularly).
>Those examples would actually be fine if this were something only did once in awhile (or in a script). But I search from the command line many times per day when I'm working, so I prefer a more streamlined interface.
Makes sense. If I had to do this frequently, I'd add a function/alias encapsulating that `find` incantation to my .bashrc, which I keep in version control along with other configuration files in my home directory. That way, when moving to a new environment, I can just clone that repo into a fresh home directory and most of my customizations work out-of-the-box.
Yeah I do the same sometimes, at the risk of going too deep into personal preference. A couple of notes about that approach:
1. I don't recommend using shell functions or aliases for this (e.g., `bashrc`) because then these scripts can't be called from other contexts, e.g., like Vim and Emacs builtin support for shell commands. This can easily be solved by creating scripts that can be called from anywhere (my personal collection of these scripts is here https://github.com/robenkleene/Dotfiles/tree/master/scripts). Personally, I only use Bash functions for things that have to do with Bash's runtime state (e.g., augmenting PATH is a common one).
2. The more important part though, is I don't always want to search in `*.foo`, I want a flexible, well-designed, API that allows me to on-the-fly decide what to search.
#2 is particularly important and drifts in philosophy of tooling, a mistake I used to make is building my workflow today into customizations like scripts. This is a bad idea because then the scripts aren't useful as your tasks change, and hopefully your tasks are growing in complexity over time. I.e., don't choose your tools based on your workflow today, otherwise you're building in limitations. Use powerful tools that will support you no matter what task you're performing, that scale practically infinitely. "The measure of a bookshelf is not what has been read, but what remains to be read."
>some of the default tooling feels dated: GNU coreutils and friends are often stuck around mid-2000s versions
That’s because they’re not GNU coreutils, they’re BSD coreutils, which are spartan by design. (FWIW, this is one of my theories for why Linux/GNU dominated BSD: the default user experience of the former is just so much richer, even though the system architecture of the latter is arguably superior.)
Couldn’t it be the other way round, that changes in health caused by other external factors erroneously get blamed on COVID?
For instance, a disproportionate amount of long COVID cases are reported by women between the ages of 40 and 60, the exact age range when most women experience menopause [0]. Menopause can cause brain fog, fatigue, and other symptoms that mirror those of long COVID. Since pretty much everyone has had COVID, it’s a basic statistical certainty that many women caught COVID exactly when their menopausal symptoms started (whose onset can be extremely sudden), and falsely causally associate the two. The exact same conflation likely happens in children, who also go through several profound developmental shifts.
>It is possible, but not to the degree that all long Covid cases are being confused with external factors.
Didn't mean to imply that all cases are, just that our definition of and knowledge about long COVID is nebulous enough that some nontrivial proportion of cases are likely attributable to external factors.
>Additionally, long Covid can cause brain fog. This was shown in brain scans from a popular HN post about a research paper just yesterday
Absolutely, just as other infections can cause severe lingering symptoms [0]. But we don't really know how prevalent these are, nor the severity of the prevalence. Studies like the one you link typically select for the most severe cases. We don't know whether it's useful to generalize from those.
You can't see "brain fog" on any imaging scan. That study didn't demonstrate any such causation. At most you can establish a correlation between certain imaging patterns and patient symptoms (which are notoriously noisy for any sort of behavioral health condition).
I went on vacation, had a great time, then got COVID, and came back a completely nonfunctional wreck beset by random adrenaline dumps, heart palpitations, spontaneous panic attacks, and wicked insomnia. The condition lasted almost a year.
39 year old male. I was in great shape both physically and mentally before my trip.
Fine, here's a source where both the second and corresponding authors are from Harvard that says the same thing [0]. That said, you don't need to be from a prestigious institution to observe the basic statistic that long COVID is most frequently reported in women ages 40-60.
So many puzzles like this basically require you to brute-force the solution [0], which just isn’t all that fun. I’m glad the designers explicitly acknowledge they’re trying to avoid this, and really hope that their claim that this actually can be solved with logic holds true:
What if instead of doing the full colored puzzle, we find partial sets of tiles where there is only one unique solution? This adds enough constraints to the problem that it becomes feasible [without resorting to brute force].
It's a real shame its raster functionality wasn't integrated into Illustrator. Adobe really butchered the whole Macromedia portfolio, didn't they?
(For those unfamiliar, Illustrator is a pure vector graphics editor; once you rasterize its shapes, they become uneditable fixed bitmaps. Fireworks was a vector graphics editor that rendered at a constant DPI, so it basically let you edit raster bitmaps like they were vectors. It was invaluable for pixel-perfect graphic design. Nothing since lets you do that, though with high-DPI screens and resolution-independent UIs being the norm these days, this functionality is less relevant than it used to be.)
Right, the vast majority of compute for autonomous warfare will be at the edge. The latency/jammability of having to communicate with a massive datacenter halfway around the world running bleeding-edge models is a nonstarter. Not to mention that these models are overkill for something like an autonomous suicide drone that just needs a relatively simple CNN trained to recognize enemy uniforms/materiel/buildings/etc.
Another issue would be permissions: if I wanted to restrict access to a file to a subset of users, I’d have to make a group for that subset. Linux supports a maximum of 65536 groups, which could quickly be exhausted for a nontrivial number of users.