Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

An anonymous reader writes "I currently maintain a browser extension within my organization that greatly facilitates several workflows. Obviously the extension not for public consumption. It appears that all the major browser makers are going to completely block extensions not made available through their various "stores" for any users not running the development version of the browser. Frankly, that's a huge pain in the ass. Are we the only ones who use custom browser extensions?"

A web developer should know what SSL certificate is, what CA is, what happens when the cert expires.
A database developer should know to not store plaintext passwords in the database and use hash instead. Salted hash.
The applications on Windows nowadays use assembly manifests that contain publicKeyToken - SHA1 hash of public key used for signing the assembly. I would expect a competent windows developer to know that.
When developing a game you want to prevent rogue modifications of game client that would give the player an advantage (there is probably a term for that).
If you use ssh to access the CVS you should know about public-private key cryptography. If you use git, you should know what a hash is. If you deploy to a staging server you hopefully do that with encrypted protocol.

Yes you can do without that. You can build walls around your sandbox and delegate all those pesky troubles to someone else. IMHO in IT it requires conscious effort to not know some basics of cryptography.

Can you elaborate, please? Let's say the network interface comes up and I (as a human) expect that my home-made network daemon starts up. But it does not. And by "it does not start up" I do not mean that "the daemon process is exec()-ed but exits immediately for some reason". I mean "the exec() call does not happen at all". Perhaps some stupid reason I failed to properly explain to systemd that it should be started. How does systemd know that a human expected the daemon to start?

With startupd, launchd, SMF, and SystemD you set the triggers for each event. No long scripts loaded with nested if/else statements galore or expensive proprietary software to mask this lack of functionality in init.

Okay, I'm always willing to learn, so please, give me a lesson. I set up a trigger for the event and the trigger does not fire. What do I do? In case of the "long script with nested if/else statements galore" I'm pretty sure what do I do there - put in some echo statements to verify the execution path. What do I do with systemd?

Are you qualified to say that? I use Slackware on server and desktop and it fills all my admin/office/development/multimedia needs. What makes it 1990s-era relic? Because it does not have dependency checking? Bah.

So long as Slackware, Gentoo and LFS exist I don't see how anyone has been FORCED off of Linux or onto the BSDs.

Maintaining a distro that does not use systemd when almost every project (package) expects systemd is not trivial. The danger is that the distro maintainers just throw the hands up and say "fuck that, I don't have energy to wrestle with this anymore". And then the users will be FORCED off.

I don't know about "unify them". As far as I can see, it is trying hard to hide the complexity under one umbrella. And if the complexity is hidden completely, then there is little you can do to fix a problem that happens to be complex. Without this unifying effort I can easily plug in myself somewhere in the middle, track down what's going on and fix it. Or at least work around it. Ah, yes, I'm a Slackware user. Is that relevant?