92 karma · joined April 9, 2014
These types of debs cause problems with system upgrades and I groan whenever I see something that uses checkinstall or similar; there are add-on deb sites that basically do that, and you get a mess in the resulting system. A lot of this is why snap got made.
I'll admit that the Debian package format could be better in this regard, but the packaging format is primarily for use by dpkg-buildpackage and building the distro.
Disclaimer: this is my own views and not those of either the Debian or Ubuntu projects.
What is the problem with distributing a tarball if you're sending binaries?
If you're making debs, you still need to make a Debian repo and sign it, and then you still have the problem your dependencies are fucked up or won't easily work across versions.
What are you trying to solve that a tarball or rsync can't?
Debian and Ubuntu automatically resolve shared library dependencies are build time through dpkg-shlibs and friends. Debian's maintainer manual is likely the most detailed guide: https://www.debian.org/doc/manuals/maint-guide/start.en.html
However, it's a bit hard to grok, so I'm going to point people at the guide that got linked in the comments before I got here: https://saveriomiroddi.github.io/Learn-to-prepare-PPA-packag...
Now we're getting to the point that this feels like a protection racket. It, at least in theory, is possible for individuals to get EV certificates for websites. Worst case scenario, you can get a one man business for the paperwork.
A lot of viruses can hit via either remote code execution, or exploiting a bug when loaded through a data file. Neither of those scenarios is stopped by SmartScreen. At best, it stops someone from clicking "WannaCry.exe".
MSFT is basically doing everything to make you use the Store, and it reeked back with Windows RT, and it reeks even more now.
Unfortunately, it seems MSFT is incapable of creating a version of Windows that doesn't have live tiles, constantly tracking what applications you run. I switched to Linux years ago, but I realize that most people live in a Windows ecosystem, and that they're subject to the whims of MSFT.
Love it or hate it, choice is a good thing. They may be getting to the point that I'd seriously look at it for a few non-essential production servers running Debian and Ubuntu.
If you want a dumpster fire for development work, I'd highly recommend HP-UX. HP-UX's stdio wasn't very std back in 1990s. What I remember is a bunch of syscalls seemingly existing but not actually working despite being OK with the same code on Solaris and Linux.
Somewhere around 2003-4, it appears all development basically consists of security patches and new Itanium hardware enablement, and aCC barely supported anything C++ related; its more like trying to use Borland C++, and GCC was really iffy, although it had the advantage that post PA-RISC, HP did adopt ELF.
As I remember, and if I'm wrong, I'll correct it, the different on 32-bit was that stdcall and pascal change the order of how arguments are injected.
It just took me a few years (or maybe decades) from reading about it to actually try it.
I've been down that road, there's nothing good to say about it.
Also, since I'm on the topic, any chance slashdot will go back to an open source code model?
We've been discussing migrating over to PostgreSQL and rearchitecting the database to run on stored proceedures and views; almost all the DB calls are already abstracted in MySQL.pm, so this is relatively straight forward (if a bit tedious).
What got me upset was the fact that I respect users privacy, and to find out about this behaviour from a bug report notification pissed me off. In /code's defence, at that point, it was basically /., /.JP and Burrapuento as the last three slash sites on the internet so a lot of slashdot specific functionality has creped in over the years before the code drops stopped in 2009, with the documentation for independent sites being a bit stale.
EDIT: I've written a follow up on my SN journal: http://soylentnews.org/~NCommander/journal/277