pengaru
full disclosure: they're my employer
drive-by comment: unintentional napping seems likely to occur more in those failing to get actual restful sleep on the regular. Don't we already know chronic sleep deprivation correlates with dementia/alzheimers risk?
But the wonderful thing about these places is they can create/acquire/prop-up small subsidiaries. If they're self-aware enough to know the oppressive force at their size, they leave these offshoots alone (until too big, where the cycle repeats anyways). These are the parts where you can still experience the magic being discussed.
Presumably working at X Development (formerly Google X) still has a lot of this energy and autonomy.
I'm pretty confident in saying it's far from zero.
There's a reason he didn't say profit...
Not saying I agree with the sentiment, just noteworthy and perhaps something to reflect upon while judging behaviors aligned with this perspective.
Watch Office Space if you haven't already. That's what most of the irl white-collar existence really reflected throughout my career. And unless you actively pursued (and arguably created in part yourself by seeking out, showing up, and participating) something special even back then at a startup, you were very likely missing out then as much as now.
There are still people making things, irl even. I'd be surprised if Tenstorrent didn't have an environment like you're pining for, or Tilt Five.
- a subaru forester owner who wanted to like the vehicle but is tired of oil leaks and counting the days before a head gasket lets go
https://en.wikipedia.org/wiki/Chaparral_2J
https://en.wikipedia.org/wiki/Brabham_BT46#BT46B_%E2%80%93_t...
https://en.wikipedia.org/wiki/Gordon_Murray_Automotive_T.50
I don't know of any others, and it's a horrible idea for anything used on public roads.. even on the race track these cars were notorious for leaving a cloud of debris/dust in their wake
someone should inform the orange POTUS of this: https://www.architecturaldigest.com/story/did-donald-trump-j...
My impression is this is a modern civilization stupidity in general.
as is ext4
and that seems like something btrfs should fix at some point
You linked copy_file_atomic_at_full(), why? That function is not in the normal rotation path for journald, it's only used in a workaround when clearing FS_NOCOW_FL fails.
Rotation does not rewrite the log file normally, but there is a hole-punching operation though for reclaiming unused space.
https://github.com/systemd/systemd/blob/main/docs/JOURNAL_FI...
There was mailing list discussion at the time journald was conceived though, you can find it if you look.
https://0pointer.de/blog/projects/the-journal.html might be a good entry-point.
the last time I contributed to journald upstream was to fix a degenerate behavior with many journal files: https://github.com/systemd/systemd/commit/176f73272e6e3116ca...
that makes a dramatic difference for those hitting this case, but it only gets things from nearly unusable to slow-as-usual.
But I never really made any effort to change the on-disk structure or how writes were performed. My focus was more on the read performance for journalctl and stability of the daemon.
Back when I was paid to fix things in journald at CoreOS ages ago, it couldn't even avoid getting killed by its own service watchdog.
My impression back then was the on-disk format dispersed the information too much within the same file, and those individual datums being written at discontiguous offsets were quite small, far smaller than an IO block size or even a disk sector size.
Seemed like a write amplification problem due to the file format. If you write a few bytes into some arbitrary position within a file, the storage has to write back the whole block, despite your only changing a tiny fraction of it. If those few bytes happened to cross a block boundary, guess what? two blocks get written.
The format had no consideration for these block-oriented storage details, then doing the IO via mmap rubs salt into the wound since the kernel has to try guess what to prefetch asynchronously... but I don't think that aspect amplifies the writes above what plain buffered IO would do - maybe I'm wrong. I'd expect the mmap aspect to be causing more/mispredicted reads, and polluting the page cache with unrelated contents (you tend to end up with the entire journal cached IIRC, if you have enough memory). I suppose there's probably compounding of the write amplification problem since the kernel will be dirtying pages at page size granularity vs. 512b sectors, and you have the same issue of small writes landing on page boundaries dirtying two pages. So that aspect of using mmap for the writes probably is exacerbating the problem.
> Intel developed QPI at its Massachusetts Microprocessor Design Center (MMDC) by
> members of what had been the Alpha Development Group, which Intel had acquired
> from Compaq and HP and in turn originally came from Digital Equipment
> Corporation (DEC).[8] Its development had been reported as early as 2004
QPI was Intel's answer to the competition AMD's Athlon / HyperTransport had created