You should have backups. Preferably also snapshots. Then rm will feel less scary.
You should have backups. Preferably also snapshots. Then rm will feel less scary.
Boox Tab Ultra
Looks pretty nice device! Even the camera makes a bit sense in the demo they give (though apparently in practice the scanning rarely works). And cheaper to boot as well. I might consider getting this one.
But is the display really better quality? Atleast the DPI is slightly higher at 219 on the Boox Tab Ultra vs 190 on the Daylight. And Boox weighs 70 grams less, and that’s the device some reviews call heavy (and some lightweight…).
These reviews mention the slow display speed:
So perhaps there is some room for improvement? That being said, some other reviews don’t mention it and one says it’s faster than typical e-ink display, though that doesn’t sound immediately purely praising.
In the end it probably comes to the software: how fast it is, it well it works, how nice it is to use. It seems both have customized the standard Android, so I suppose the difference is in which one has done it better and which one has better custom apps. Per the reviews Boox doesn’t fare too well in this aspect. Maybe someone will make a comparative review of the devices.
As opposed to buing a separate display for the computer?
I like to think this thing would be nice reading the news while having a breakfast or reading an e-book outside or at the bed, not near my computer. So it makes a lot of sense to build a tablet with this display technology.
Zooming and panning a pdf is arguably more comfortable with higher frame rate.
What a nice succinct explanation!
But also completely useless. Run0 ignores the suid bit for the same reason as 99% of command line apps do: it ignores because it isn’t relevant to its functionality.
Would that kind of provision allow me to have my code removed from a git repository history, if that git repository is hosted by a company?
I think the second point is the biggest for me: it’s almost like Canonical wanted to have a single dominant store for apps, as the ecosystem they are building supports only one. And, apparently, that one server is also closed?
So if you try to make an alternative source and give instructions to people how to configure their snap installation to use it (I found this information very hard to find for some reason…), your “store” probably won’t have the same packages Canonical’s has, so users won’t be able to find the packages and I imagine updates are also now broken?
Contrasting this with flatpak: you just install apps from wherever. Or from flathub. Or your own site. Doesn’t matter. No business incentive behind—built into the tools—to make everyone use flathub.org.
I just noticed https://lemmy.ml/u/giloronfoo@beehaw.org had proposed the same, but here’s the same but with more words ;).
I would propose you try to split the data you have manually into logically separate parts, so that you could logically fit 0.8 TB on one drive, 0.4 TB on another, and maybe sets of 0.2TB+0.2TB on a third one. Then you’d have a script that uses traditional backup approaches with modern backup apps to back up the particular data set for the disk you have attached to the system. This approach will allow you to access painlessly modern “infinite increments” backups where you persist older versions of data without doing full and incremental backups separately. You should then write a script to ensure no important data is forgotten to be backed up and that there are no overlapping backups (except for data you want to back up twice?).
For example, you could have a physical drive with sticker “photos and music” on it to back up your ~/Photos and ~/Music.
At some point some of those splits might become too large to fit into its allocated storage, which would be additional manual maintenance. Apply foresight to avoid these situations :).
If that kind of separation is not possible, then I guess tar+multi volume splitting is one option, as suggested elsewhere.
By that logic, is the compositor working any different than a trojan? Is there really a difference?
The Wayland compositor is always capturing all your keyboard and mouse as well. No permissions asked. Pretty sus.
I have 64GB RAM and my 64GB swap still gets filled to 60% over time.
It just happens so that apps end up touching some memory once that they never then use again. Better use some SSD for that instead of RAM.
I suppose it explains why people have a bad attitude about Wayland when tools providing useful functionality are described as trojans.
X11 can (…mostly…) have great security by just providing a suitable X Security module to it. It just seems it wasn’t considered that big of an issue that anyone bothered. Nokia Maemo/Meego used to rock such a module.
It’s two commands to grow the / fs on the fly:
lvextend -L+10G /dev/mycomputer-vg/root
resize2fs /dev/mycomputer-vg/root
So don’t worry about it. LVM is great :).
It doesn’t actually detect moved code, though, like git diff
can? I gave it a shot and also there’s a couple issues open about it, e.g. https://github.com/Wilfred/difftastic/issues/520 .
Other than that, difftastic is quite nice.
What do you mean? Matrix supports E2EE.
Its not used with e2ee, is it though? At least it’s not the default and I doubt it can even be enabled.
So what is the security flaw assuming we weren’t using e2ee to begin with?
Unless you mean that the simple client should still provide other people that have non-simple clients URL previews, which would only be accomplished if the server generated them.
Yes, like RSS bots, bridges, webhook-bots etc all can produce links the recipient might want to see previews for.
Another thing is that e.g. spammers might choose to use a misleading preview. Though I suppose that’s a minor point, probably server-side previews can be tricked as well.
What is the security/privacy flaw if the server does it? No point thinking a non-encrypted would be very secret in the first place.
I guess the idea is that this works with simpler clients as well. Other nessaging networks with initiator-side previews usually have single-provider clients, as far as I know.
Initiator-generated previews would be a nice feature, though, and they would work with e2ee.
I use etckeeper to autocommit changes in /etc as git just has better and faster tools to look at the changes of a fle, compared to backup tools.
It’s just so easy to do that there hardly is any point in not doing it.
If you can do that, you already had enough space for reflinking not to matter in the first place, right? Or you can carefully do defragmenting in parts, running dupremove incrementally? seems like a lot of wasted time :).
Here’s one sharp edge: defrag will unshare file contents so sometimes it’s not just feasible to do it.
But how many use it for browsing, which I imagine this data is from?