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").
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.
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.
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)
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 :)
- 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.
And there is another Apache project : Apache Hue, as a django web app
I d put between group 1) and 2). Not in 3), because there is not "quick charts", and datasources are not managed at application level but in configuration files and require more "administration" tasks.
The first room is obviously already filled.
Each character formatted as a link is a door to a subroom : CTRL+ENTER to go to this room.
ESC to go back.
If you find some white space, you can type a character which will be unformatted.
Move cursor to an unformatted character and use CTRL+SHIFT+Enter to make it a link to a new empty room.
I m not sure everybody knows how long this concept has matured, and I cannot prevent myself to quote XUL (I wrote thousands of lines of XUL and I loved how it was easy to create GUI for this time)
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.
I really agree. I described the current state.
As my next comment explain it more, there is room for improvements.
Is the "write once run everywhere" paradigm a realistic goal, would it be achieved at runtime or at code generation/compilation, without an unbearable cost for users ? I want to believe.
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 :)
Am I the only one who see the same story repeated again ?
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.
The saddest thing is that since "ego depletion is a normal thing for every human" is no more a reliable concept, people will miss an explanation for their forthcoming loss of will power or failures in their life :)
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").