I should just change my opening to "This is your host NCommander, and once again, I'm suffering through X" :)
HN user
NCommander
Ubuntu Core Dev, World Traveller, SoylentNews Administrator. Loves meeting people, and changing the world.
Instructions unclear, currently at bottom of the Pacific. Found Integrity hardware, but nothing actually useful.
If I had one, I'd look at doing so :)
I use DaVinci Resolve 17 for primary video editing, plus Fusion for basic composition. Blender was done for most of the animation work (the semaphores being fusion compositions instead cause I was lazy). Audio is recorded in Resolve, but post-processed through RX Elements 8, and music is from the YouTube library.
No, I'm aware it is. Most of the problems is people trying to use it to distribute binary source code. Using it for source builds and debian/rules is a lot saner and straight forward.
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.
The best equivalent I can give is this is roughly like opening up a MSI file, and replacing its guts. It works but you're asking for a really fragile system in return.
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?
Wow, this is horrible advice. I'm a Debian Developer and an Ubuntu Core Developer. What this will do is create a package that doesn't properly handle dependencies and be incredibly fragile.
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...
The entire point of authnicode wasn't to protect users, it was to make sure software wasn't modified in flight (ala what SourceForge did), and to make those binaries accountable.
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.
I'm happy to see this project going onward due to the fact that systemd continues to be a giant sore that keeps entrenching on the entire stack. If nothing else, it means that a usable Linux distro w/o systemd is viable.
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 are the copyright holder, you can put a OpenSSL exception clause in your license which allows this to work. Debian requires such a clause for GPL software to link with OpenSSL prior to this change.
AIX at least has LLVM, and IBM had unofficial GCC ports for years.
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.
It does in Microsoft's world who #define it like that.
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.
IBM Mainframes laugh at Windows backward compatibility. 50-60+ years isn't unheard of. I actually want to at some point climb that cliff but my next write up is exploring Windows 3.11's networking features, and then Novell NetWare; the Windows one should go up tomorrow on SN, and NetWare next week.
Even for Windows 1.0, I can see ways to cut this thing down to size. The point though is that this is what MSFT actually included in the SDK, and I remember reading about in "Programming Windows" and other sources.
It just took me a few years (or maybe decades) from reading about it to actually try it.
They did in 32-bit Windows (NT3.1 is pretty much the same on a core level from Win 10). The problem here was that the 8088 suffered from segmentation which put "interesting" constraints on programs, and then Intel's 80286 was alded to the point that it was only successful in the sense of "faster 8088" and not bringing 32-bit computing as was promised.
No, not really. You can get chroots to run on a command kernel but ABI changes happen without soversion bumps which stupidly complicate matters. Godhelp you if your application tries to use weird ALSA or even worse, OSS features.
I've been down that road, there's nothing good to say about it.
I'm fine with either showing up, although it originally was posted to SoylentNews (which I'm a site administrator), and then sent to neozeed to post as SN deals with news more like HN and I didn't want it to get lost in the archives. It's also on DEFCON 201's blog.
You're welcome. I just got tipped off on this ending up here. The rabbit hole was incredibly deep, but by time I was out of it, I was determined to share the pain with the rest of the world :)
Are there any plans to push this code back upstream to Apache? My understanding is SF.net abandoned the legacy alexandria (the PHP code from VA Linux) source code, built the current version, and then sent to the Apache Foundation, but I'm not clear if this is a fork, or what sf.net's relation is with it's upstream.
Also, since I'm on the topic, any chance slashdot will go back to an open source code model?
Actually, the "don't have IP address" is a sanity check if this code fired from slashd; if someone coming in from the web interface, the GATEWAY_INTERFACE var is always set by mod_perl.
backslash (the admin interface) is fragile, during beta testing, we got the site stuck in an infinite loop because the UI for topic creation is not the greatest. I'm not sure I get the 'stores weblogs in mysql' bit as wordpress by default does the same thing.
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).
Slashdot.JP (which is owned by ODSJ), and BurraPuento. At the time this code was added to the repo, macslash was also up.
I don't mind portscanning per say if its clear you're doing it but a website should never trip a corporate firewall or IDS. We're going to re-rig this code to check the inbound IP against a local DNSBL or something similar and not something that will cause an IDS to shit itself. Generally, if I access a site on a port, I expect return traffic to come back only on that port (excluding protocols like FTP which are explicately multi-port). We officially support tor (and have our own hidden service) and are looking at connecting posts through SpamAssassin to automoderate crap down to -1 (this feature still fairly far out)
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