![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://fry.gs/pictrs/image/c6832070-8625-4688-b9e5-5d519541e092.png)
Do you really want to know? There are some things that the human mind is not meant to contemplate.
Do you really want to know? There are some things that the human mind is not meant to contemplate.
This seems like a very complicated way to achieve your goal! It sounds like sitting yourself down and giving you a stern talking to might be a beter aporoach.
Having said that, if you have these very important files that you don’t want to lose, please make sure they’re backed up somewhere off of your machine. Storage fails, and it’s a horrible feeling losing something important. Unfortunately doing so would defeat the approach you’re thinking of.
This might be a case of needing to reframe the question to get to the cause of the issue, and then solve that. So, why do you want to make it hard to reinstall your machine? Is it the amount of time you spend on it, the chance of screwing it up, needing it working, has it become a compulsion or something else? Maybe if we can get to the root of the issue we can find a solution.
With regard to TPM, it’s basically just a key store, so you can use it fir anything really, althought it’s normally used by generating a TPM key and using it to encrypt the key that’s actually used to encrypt your data, storing the encrypted key with the OS. Just reinstalling won’t wipe the TPM, but unless you made an effort to save the encrypted key it’ll be gone. Given your problem statement above it just adds to the data you’d need to save, which isn’t helpful.
Ok, I’m still not clear on exactly what you’re trying to achieve as I can’t quite see the connection between somehow preventing certain files being duplicated when cloning the disk and preventing yourself from reinstalling the system.
Bear in mind that reinstalling the system would replace all of the OS, so there’s no way to leave counter-measures there, and the disk itself can’t do anything to your data, even if it could detect a clone operation.
If what you’re trying to protect against is someone who knows everything you do accessing your data, you could look to use TPM to store the encryption key for your FDE. That way you don’t know the password, it’s stored encrypted with a secret key that is, in turn, stored and protected by your CPU. That way a disk clone couldn’t be used on any hardware except your specific machine.
Nothing can prevent a disk clone cloning the data, and there’s no way to make something happen when a disk is cloned as you’re not in control of the process.
If you wish to mask the existence of the files, use either full disk encryption, in which case cloning the disk doesn’t reveal the existence of the files without the decrypt password, or use a file based encrypted partition such as veracrypt in which case the cloner would just see a single encrypted blob rather than your file names.
Ultimately encrypting the files with gpg means they have already effectively ‘destroyed or corrupted’ themselves when cloned. If you don’t want to reveal the filenames, just call them something else.
If you could be a bit more specific about your threat model people may have better ideas to help.
It sounds like you’re actually more concerned about the data in the files not being able to ‘pop up’ elsewhere, rather than the files themselves. In thus case I’d suggest simply encrypting them, probably using gpg
. That’ll let you set a password that is distinct from the one used for sudo
or similar.
You should also be using full disk encryption to reduce the risk of a temporary file being exposed, or even overwritten sectors/pages being available to an attacker.
Putting a simple preseed file on a debian install image is probably going to be your best bet. Assuming you can run a VM on your current machine it shouldn’t be too difficult to test it until you’re happy with it.
It’s going to be a balance between your time getting an automated approach to work and the cost/effort of getting a monitor. Getting preseed working can be a bit fiddly, but it does mean you’ve learnt a new skill, getting a monitor sounds like it’ll be a pain, and you might only need it once.
Yes, that’ll work too, it does involve adding the disk to your machine temporarily though, so just be carefully which disk you format to do it. Please don’t ask why I say that, it brings back painful memories…
While I agree with most people here that finding a keyboard and screen would be the easiest option, you do have a couple of other options:
Use a preseed file A preseed lets the installer run completely automatically, without user intervention. Get it to install a basic system with SSH and take it from there. You’ll want to test the install in a VM, where you can see what’s going on before letting it run on the real server. More information here: https://wiki.debian.org/DebianInstaller/Preseed
Boot from a live image with SSH Take a look at https://wiki.debian.org/LiveCD in particular ‘Debian Live’. It looks like ssh is included, but you’d want to check the service comes up on boot. You can then SSH to the machine and install to the harddrive that way. Again, test on a VM until you know you have the image working, and know how to run the install, then write it to a USB key and boot the tsrget server from that.
This all assumes the target server has USB or CD at the top of its boot order. If it doesn’t you’ll have to change that first, either with a keyboard and screen, or via a remote management interface sych as IPMI.
The article says:
The photons travel through a resonant metasurface, where they mingle with a pump beam.
From that, I think it’s suggesting it needs a separate beam of photons to amplify the signal, much like a transistor needs a supply current to amplify the signal it gets.
They also say:
This new tech also captures the visible and non-visible (or infrared) light in one image as you look through the ‘lens.’
Which sounds like it produces an image showing both the IR and visible spectrum in the visible range.
Mind you, re-readind it, most of the article just talks about IR, so I’m not certain what it’s actually doing. It could just be transparent to the visible spectrum. It wouldn’t be much good for driving if it did that though, the windscreen blocks a lot of IR and you’d need IR headlights!
The material captures visible light too, so headlights would be brighter, but I wonder if there’s a way to reduce the contrast by either filtering out some wavelengths (like driving glasses) or the material simply not boosting it’s output past a certain level?
The device captures visible and infrared light, just like a typical night vision scope. They’re working on expanding the spectrum too, which could lead to some interesting and useful results. I understand that, for instance, skin cancers are more visible under certain UV wavelengths, so imagine a doctor being able to just put on a pair of glasses that convert that wavelength to give you a once over during a checkup.
I believe so, but that’s definitely something you’d need to check yourself.
You shouldn’t need a window manager, you should be able to pass a tell mpv to just run full screen.
Alternativly, if you’re up for a bit more work, it looks like you can get mpv to run in tge framebuffer and so not need ecen X11. It might take recompiling a few packages, I’m not sure whether the options are built by default now, but you could have a look at this thread fir example: https://bbs.archlinux.org/viewtopic.php?id=176072
It doesn’t really matter whether the FMR is one in a hundred or one in a million, for the uses it’s being put to it’s still too high. If it was only being used as one factor for authenticating someone (I.e. the ‘thing for are’) but still required the other factor(s) (the ‘thing you know’ and the ‘thing you have’) then it’d be adaquate.
As it stands, when it’s being used either to pick someone out without further scrutiny, or to make payments with no further checks, it’s simply unacceptable. There’s good arguments to say it’s not just the error rate is unacceptable, but that the technology simply shouldn’t be used in those scenarios as it’s entirely inappropriate, but that’s a separate discussion.
It’s the same problem with a drive like this, or any long term archive, you either store the data unencrypted and rely on physical security, or make sure you store the encryption key and algorithm for the same length of time, in which case you still need the physical security to protect that instead. In both cases you need to make sure you preserve a means to read the data back and details of the format its in so you can actually use it later.
Paper is actually a pretty good way of storing a moderate amount of data long term. Stored correctly it’s unlikely to physically degrade, the data is unlikely to suffer bitrot and it can be read back by anything that can make an image in the visible spectrum. That means you can read it, or take a photo and use OCR to convert it into whatever format is current when the data is needed.
That may be your perfect search engine, I jyst want proper boolean operators on a sesrch engine that doesn’t think it knows what I want better than I do, and doesn’t pack the results out with pages that don’t match all the criteria just for the sake of it. The sort of thing you described would be anathema to me, as I suspect my preferred option may be to you.
I’m not disputing that he doesn’t think the issues are major, as I said, he’s usually pretty ambivalent about what runs on the kernel, so they’re not issues he cares about. On the flip side, I do care what is running because I have to manage and support it.
I do wonder if we’re talking at cross purposes though. You seem to mostly be talking about the systemd init system, I’m mostly talking about all the other bits it, as a sort of umbrella project, tries to encompass. I don’t much like the init system, I prefer to be able to explicitly set the ordering of the steps, rather than having them inferred, and I prefer shell script that I can test to unit files, but it mostly works ok. So does every other init system though, so it’s not a selling point.
As I said, the big problem is around how they’ve tried to do everything, much of it less well than what they’re replacing. Yes, you can build a system that uses systemd-init and none of the other components, but that still drags in a load of other dependencies, so you might as well use a different init that’s smaller and cleaner.
We came close to the ‘systemd apocalypse’ recently, when distros hooked the systemd library into openssh without understanding just how bloated it is and how many poorly monitored dependencies it brought in. It was just luck that the right person spotted a slight change in timing and investigated.
Ultimately I suppose it comes down to the level you interact with your systems at. If you just want to install your OS, a few packages they directly support and let it get on with it, then you probably neither know nor care that you run systemd, and that’s great. On the other hand, in my experience, when you try to push the system past that and do anything more customized you start running into the sharp edges and misfeatures on the various systemd components.
I obviously find the arguments against systemd more persuasive than you do, and that’s fine, it’s all open source and we can all make our own choices about it. My experience with it over the years has been, and still is that it vastly over complicates things that used to be simple, often the less commonly used parts just don’t work right (the automounter is a particular bugbear of mine, and few distros seem to use the network management component). The arguments do matter in practical terms as they directly impact how it works.
Of the distros you mentioned, centos is a RHEL derivative and so wasn’t independent, arch packages multiple init systems, but yes, I’d forgotten opensuse, and they seem to be firmly in the systemd camp.
I may be an internet rando, but I’m not actually angry, more just disappointed. I’d agree with Mr Torvald’s opinion that some of the design details are insane, but I think they are more fundamental than just ‘details’ as many are to do with the fundamental concepts around what systemd is and how it works. Linus can be a real dragon around changes to the kernel, but he’s always tended to be more relaxed about the layers above it.
That the developers of systemd are ‘much too cavalier about bugs and compatibility’ is surely clear to anyone who follows the relevant mailing lists and bug trackers, and should alarm everyone.
I was more suggesting that it might be a bit eldritch, but sometimes humor doesn’t come across quite right/
The linked paper is focused on studying the ‘perforation-type anchor’ they use to hold the tissue to the mold as it grows, rather than keeping it alive afterwards. During growth the tissue and mold were submerged, or partially submerged, in a suitable medium to keep the cells healthy, and it was only when the resulting models were tested that they were removed (although one test did seem to involve letting it dry out to see if the anchors held). Growing the various layers of cells seems to be a solved problem, and I suspect that includes keeping them supplied with nutrients and such, so the authors aren’t examining that. What’s not solved is how to keep the tissue attached to a robot, which is what the authors were studying.