Hacker Newsnew | past | comments | ask | show | jobs | submit | hartmel's commentslogin

I ll add that the usage "cassette" refers usually to a tape in a plastic case, like the VHS cassette, the audio cassette.

The words referred to a box where coins where stored. It s probably still used in banks, like when ATMs are refilled.

Surprisingly for "LTO tape", french mostly uses the literal translation of "LTO tape" and sometimes "LTO cartridge" too ; the use of "cassette" is uncommon.

I just discovered it's the word for a bicycle component too.

There is the word "caissette" too, which is a box, small but not necessarily extra small as the "ette" prefix usually suggests in french though. I guess it depends of the context. ("Caisse" == "box")

There is yet another word for small boxes made of wood usually used for vegetables and fruits: "cagette".

"Casse" exists too with another meaning : it s a vehicle graveyard. (It comes from the translation of "to break" wich is the verb "casser").


> I ll add that the usage "cassette" refers usually to a tape in a plastic case, like the VHS cassette, the audio cassette.

It only acquired that association due to the prevalence of audio and video tapes being enclosed in cassettes from the 1970s on, and will likely lose it as time goes on.

In terms of underlying meaning, "cartridge" and "cassette" are largely interchangeable, and on the other end of this, there are situations in which "tape cartridge" has been a common construction (especially with backup tape drives that were common in the '80s and '90s). 8-track tapes have also historically been called cartridges.




There is SCEP (https://en.m.wikipedia.org/wiki/Simple_Certificate_Enrollmen...) which allows that and is often found on network devices. You need a PKI which exposes a SCEP endpoint (ejbca or dogtag supports this). That the certificate is used as certificate for the HTTPS is up to the device implementation of the scep client or something else in the client though.

On servers, certmonger can do scep iirc. On private infrastructure, FreeIPA provides a packaged dogtag and you can create your own certificate profiles. Clients enrolled in freeipa have certmonger installed to refresh certificates.


> You need a PKI which exposes a SCEP endpoint (ejbca or dogtag supports this).

Uhh...

> [...] ejbca [...]

Now you have two problems.

What I mean is, if you’ve been already running EJBCA for whatever reason then this is perhaps reasonable, but if your current setup is at the level of typing `openssl req` into a terminal (whether that’s a good idea or not), it sounds like a lot of additional complexity. (Can’t say anything about dogtag.)

I’ve been waiting forever for somebody to add an ACME backend to the Go SCEP library[1], but it doesn’t look like that has happened. In the meantime it includes a fairly competent standalone CA server at the abovementioned invoke-openssl-by-hand level.

Note that SCEP basically requires a trusted network, though, from what I remember.

[1] https://github.com/micromdm/scep


HSMs allows to have key stored with the option to disable key export. This means every cryptographic operation must be done by the HSM (commonly through pkcs 11 API).

HSMs have backup features and the data cannot be restored without a secret split among multiple secret holders (like https://en.m.wikipedia.org/wiki/Shamir%27s_secret_sharing). So a backup can be done on physical media and put in a safe.

It's a lot of things about key management, HSMs, pkcs interfaces to learn though.


Edit: my bad, +ssh-rsa refers to a signature algorithm using SHA1, which should not be used anymore. Target server host keys should be renewed, as told by riolu, thanks to him for pointing it.

On debian-like, remove host keys and run dpkg-configure openssh-server.

On redhat-like, remove host keys and restart sshd.

---------------------------------------------

Not vulnerable, not a bad practice. Newer algorithms are faster (in practice not perceptible, people usually don't need state of the art performance for SSH connections), with smaller keys and probably better algorithms (not subject to side channel attacks, which are still hard to abuse) but RSA is not broken. It may be in a few years with quantum computing but it's still far to be sure.

https://www.schneier.com/blog/archives/2021/03/no-rsa-is-not... updated last december.

No need to rekey all accounts or servers, just switch to ecdsa or ed25519 progressively.


That change isn't actually about RSA vs. ECC. It's about SHA-1 vs. SHA-2. The default configuration still supports using your existing RSA keys, but with a different hashing algorithm (with the options rsa-sha2-256 and rsa-sha2-512). That configuration change allows use of SHA-1 to continue.


A few year ago I was syncing keepass over http (it's built in keepass) with a Apache httpd and webdav module. Configuration was not really tricky and worked flawlessly. I even managed to use a yubikey on sync request.


I see more and more "platform engineer" in job listing, for what require the same skills as infrastructure/hosting/system engineer (regarding SaaS, at least).

Maybe the next buzzword will be "platform engineer".


Then you will want to manage the configuration file and to browse logs, and you ll have to mount files to you container. And your deployment start to reimplement (a subset to your needs) what distros did System integration complexity didn't disappear thanks to containers. It was just moved to another place. I dd add that, being convenient for developers doesn't mean it's convenient for hosting management. At the end, when one side convenience is taken in consideration, it often translate to complexity and pain at the other side. K8S become in some companies more a mandatory runtime requirement than a hosting commodity/facility.

As a (former) developer I d rather ran redis in a container during development, but for production I d rather rely on boring VMs unless some scaling is required. (Managed k8s case set apart)


> Then you will want to manage the configuration file and to browse logs, and you ll have to mount files to you container. And your deployment start to reimplement (a subset to your needs) what distros did System integration complexity didn't disappear thanks to containers.

Agree, but my view on this is that the implicit answer of how you do all that (i.e. the file system, syslog) is now gone. There will be pain (complexity) in the short term, but at the end of the day, we're going to be able to build much better orchestration and systems. To kind of restate that, before you had to worry where a process wrote out it's output (stdout? /var/log/<program>? /etc/<program>/logs? /home/<user>/<program>/logs? syslog?), now you know want to get the non-stdout/stderr logs of the thing you're running, you'd better give it a volume to write to (which may be fake, and actually write everything to some remote storage or something), and I think that's a step forward.

Of course, I'm not saying containers should go everywhere -- relying on boring VMs over containers is fine too -- but I think rich world of functionality available to container-driven workflows is popular for good and bad reasons, and the good reasons are worth exploring/beneficial to me.


Finally the biggest mistakes systemd project did is on the marketing and strategy sides.

Would have they remove the "systemd-" prefix from all side binaries and marketted them as independant projects on the website, made them usable without systemd and maybe on sub repositories, would have the systemd project just had to explain "yes we rewrite ntp, dns, etc, why not ?"

Instead they received complains about a "bloat ware" while often rewrites of industry-standard by unknown/junior people are acclaimed on HN :)

Even better, they could have integrated chronyd or others by creating "systemd integration standards" and submitting patches to these projects to gain community support and permit an easy switch to one or another implementation and let the users chose. Though it s still already easy to use something else than timesyncd on centos at least, thanks to systemd project and distri maintainers too :)


You can't have any stable integration standard when systemd's scope is ever increasing, or paper it over with marketing. Even stuff like home directories now Must Be Improved.

It isn't comparable with typical rewriting of industry-standard by newbies.


- the developer is the creator of MEKA, a (1998!) Sega Master System emulator, which had the reputation to be the best during a long time (and still may be, I don't know anymore)

- WonderBoy Dragon's Trap remake and Street Of Rage 4 for PC/consoles, it's him too

I may be wrong, but following the screenshots, the Dragon's Trap development was like : we need tools to write a game ! let's write it ! Wait we need libraries to write tools ! let's write them !

The quality of the game and all the details reflect impressive skills and amount of work.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: