For sure, but let's be honest - if us adults struggle with how good Big Tech is at making the devices addictive, the young mushy brains have no change.
Treating Linux as a monolith here is kind of missing the point. Desktop Linux and Android have an entirely different application model, a solution for Android would have to be applied in a significantly different manner to desktop Linux.
It'd likely be folded in to play services, as was the case with the exposure notification framework during covid for example.
Well it’s obviously technically feasible (which seems like the least relevant part) if you want to have zero privacy because every single general purpose computer has unremovable spyware builtin..
What am I missing about this use case? It seems like you should just create `build/.gitignore` with `*` in it and `add -f` it and be done.
I'd use `.gitkeep` (or an empty `.gitignore`) if I needed to commit an otherwise-empty hierarchy. But if I'm going to have a `.gitignore` in there anyway, it's not empty.
> The directory is now “tracked” with a single, standard file that will work even after renames.
Does `.gitkeep` not work after renames? Or `.gitignore`?
I have much more than `build` to block. IDE-specific stuff, smalls scripts I write to help me (and go in root) but don't belong in the repo, etc.
And what if for some reason you accidentally copied a big Linux ISO to that directory by mistake. Without a whitelist, you might accidentally add and commit a 700MB file to your main and not even notice. What a pain when you push later and have to git amend, rebase -i, etc.
Better to block all except whitelist. The only downside is it's less obvious how to do this than allowing all except blacklist to new git users.
It makes the behavior more obvious from simply looking at the file, for one thing, and it means you can just lump it into your next `git add -A` without needing to handle it specially.
No, not like that. There's a difference between a site that:
1) provides a snapshot of another site for archival purposes.
2) provides original content.
You're arguing that since encyclopedias change their content, the Library of Congress should be allowed to change the content of the materials in its stacks.
By modifying its archives, archive.today just flushed its credibility as an archival site. So what is it now?
> You're arguing that since encyclopedias change their content, the Library of Congress should be allowed to change the content of the materials in its stacks.
As an end user of Wikipedia there are occasions where content has been scrubbed and/or edits hidden. Admins can see some of those, but end users cannot (with various justifications, some excellent/reasonable and some.. nebulous). That's all I'm saying, nothing about Congress or such other nonsense. It seems like an occasion of the pot calling the kettle names from this side of the fence.
> What I don't see on that page is where they explicitly don't promise to not modify anything in the archive.
I'm quoting all of that because is lacks an explicit promise of non-modification /i
Meanwhile seriously, if you were disappointed not to see e.g. "We explicitly don't promise not to modify", then perhaps you should consider why, regardless, this site was trusted enough to get a gazillion links in Wikipedia... and HN.
> I'm quoting all of that because is lacks an explicit promise of non-modification.
And I'm quoting all of that because it lacks an explicit (or implicit) promise of modification. :)
It was (emphasis on past-tense) so-trusted because it advertises itself as an archival site. (The linked disclaimer is all about it not being a "long-term" archival site. It says it archives pages for latecomers. There is an implication here that it archives them accurately. What use is a site for latecomers if they change the content to be something else?) If they'd said or indicated they would be changing the content to no longer reflect the original site, Wikipedia would not have linked to them because they wouldn't be a credible source.
In any case, now I can't use them to share or use links since we can no longer trust those archives to be untampered. When I share a link to nyt content on archive.today or copy and paste content into email, I'm putting my name on that declaring "nyt printed this". If that's not true, it's my reputation.
> When I share a link to nyt content on archive.today or copy and paste content into email, I'm putting my name on that declaring "nyt printed this". If that's not true, it's my reputation.
What if the nyt article itself is the problem? How does that square?
> Meeting notes are the obvious one. Before Granola, I’d either scribble while half-listening or pay attention and try to reconstruct things afterwards from memory. Both were bad. Now the transcript happens in the background, a summary lands in my Obsidian vault automatically, and I can actually be present in the conversation. That’s 20 minutes a day I got back, every day, without thinking about it.
Yikes. So, 1) meetings at your company suck. In general, you should be engaged and take short, summary notes and todos while you're there; no need to have a transcript or AI summary. Talk to your manager about getting meetings right. 2) "without thinking about it" might not be the best phraseology in this overall context. :)
I'm glad that this is making this individual more productive, but to quote the Fortune article:
> “AI is everywhere except in the incoming macroeconomic data,” Apollo chief economist Torsten Slok wrote in a recent blog post, invoking Solow’s observation from nearly 40 years ago. “Today, you don’t see AI in the employment data, productivity data, or inflation data.”
So I don't feel like TFA is a necessarily a rebuttal to this. The proof would be in the pudding.
His argument is that this isn’t a failure of AI to perform as advertised, but a series of deployment failures a businesses. He theorizes that they’re buying a million licenses for chatgpt or copilot, dumping that in the laps of employees, and assuming the results will just… “show up”.
So I guess he’s making the case that the tools are good… the employees are just holding it wrong.
This is great! I love it when people take bits of history that works be forgotten and put them out in the world (to be further vacuumed up by Internet Archive). Thank you for doing it.
Beej! Thank you very much! Your networking guides have long been a great contribution to everybody, and collectively improves what we know.
These diary pages come largely from Stirling City, just north of Chico, and later from the Hat Creek district, on Hwy 89 north of Mt. Lassen. Nearby, many historical records were lost in the Paradise Camp Fire, and digitizing some of the records in some of the local museums is something this is a test run for.
That'll do something, but making maximally-capable individuals probably ain't it. There's a balance to be struck here.
reply