hartmel
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").
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.
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.
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.
Maybe the next buzzword will be "platform engineer".
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)
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 :)
- 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.
About 20 years ago, in 1998, Netscape Communicator 5.0 was released as an alpha version and introduced the new toolkit to build the GUI of the browser with XML, CSS and Javascript. Shortly after, the Mozilla foundation started and Netscape 6 was released.
At this time, around year 2000, it was an outstanding technology, and it could have become the defacto standard for cross platform GUIs...
Sadly, the Mozilla Foundation didn't sponsored this technology enough (in my opinion) to make it become the leader for cross-platform GUI development. Because of lack of interest as a core technology by Mofo, the problems with tooling around build and packaging, documentation, legacy components, newcomers accessibility were not resolved.
Firefox 57 removes the support of XUL for extensions but if I m not wrong it still uses XUL in some windows and the gecko engine (which render XUL).
After XUL, we saw interests of this concept of XML-based toolkits by Adobe (Flex), Microsoft (XAML), Gnome (Glade), QT (QML, maybe the winner ?), HaxeUI. There are probably more.
XUL is the oldest implementation of XML-based GUI toolkit that I know. There are probably some before.
W3C made it possible for web.
Disclaimer: I didn't feel the user experience you described. (and have a lot more experience with XUL than QML)
What I experienced is that actual performances of crossplatform "runtimed" toolkits are enough for desktops and acceptable for mobile devices, but the global overhead (compared to a binary using native OS widgets) exists, beginning with startup cost, memory consumption, i/o latency. In fact, the same constraints that VM-based languages have. And even more : the underlying GUI toolkit may be used in an unexpected way, strange GPU driver behaviours may pop up, how not to be bothered by OS fragmentation. And then an application may run flawlessly on a device with a given OS while on another it performs not that good.
While I think it's correct to say that VM-based languages does not have to blush in front of compiled programs when talking about raw computing performance, my experience (as an ex XUL-lover, I may be biased) make me think that this is still not true when UI is involved. Java has maybe the oldest (and most optimized ?) runtimed UI, and it does not convince me. OK, this may be a bad example : Java UIs are "runtimed" at a different layer. but seeing the length of the QML performance wiki page is a bit scary :)
Maybe the "1% overhead" is an unreachable dream, and maybe the native apps will become deprecated, but I think there are a place for improvements. How many attempts of crossplatform UI runtime exists ? Not that much. With hardware improvements, the overhead will be more and more acceptable. It s a huge work, and previous errors should be looked at (rant time : Mozilla: you should not have stopped to use native widgets - Adobe: Flex - QML: mimicking web dev like XUL did is nice !).
Though, I am really impressed by Qt and .Net SDKs and I would really love to see more free software and linux surprises from Microsoft with the Xamarin acquisition.
And, let's be utopic, the future is maybe about a standard API à-la POSIX for end-user applications, where OS vendors will agree on an app, and natively implement their own <button>, their own <menu>, their own <video>. They do if for the browser, for the "webassembly", why not for the OS ? Or the browser will be deeply integrated in OS and the "web" apps will replace all native applications. Or they'll still coexist for years.
OK, anything but embedding a webview would please me :)
We have now Facebook, a major actor on the web, who is developping a cross-platform toolkit for application development, using OS native widgets. XUL, I miss you :) And now others try support different OS.
Mozilla created everything and they just failed to "market" it. It s at the same time a pain and a joice to see real JS applications, shadow dom, custom components, CSS based styling being the core of a toolkit while we saw XUL/XBL/CSS/native calls from Mozilla be killed a few months ago. It had its flaws, but it s a serious (but really difficult) way to go : Qt did it, Gnome did it, Microsoft did it, even Adobe tried to do. Mozilla and people involved in previous ideas and implementations deserve a special mention for their work.
We really need such technologies, and that Mozilla killed theirs was a really sad choice for me. Creating software with "simple" markup, "simple" styling rules, "simple" event/user interaction handling should be a concrete goal of decades of languages/compilers/interpreters researches.
It has a price : performance, sometimes native look&feel not perfectly accurate, supported platform must have similarities. We may hopefully reach a level where a <button> tag will cost 1% of overhead against a native call and this will be a great day. I hope these new implementations will succeed, and that the actual overcomplexity in the web developpement will not land in though.