I have little experience with compiling from ports myself (and that was mostly on freebsd), so I cannot really comment on that, but I've used the pkg_* system for years and have yet to run into serious problems like versioning-hell or pkg's breaking. dependencies are normally well resolved when (de)installing pkg's. even upgrading works pretty well for the most part.
I agree that the package management could be better, but as far as I can tell it isn't as bad as you suggest as long as you stick to the official prebuilt packages.
or is it different when following -current ? I usually stick to releases and only patch major bugs.
This is like saying [some database] isn't as bad as you suggest as long as you aren't at the scale where you need distribution. The whole point of a package management system is how it handles the complex edge cases, not the simple linear accept-the-defaults cases.
Apt, for example, knows how to consume variant packages from alternate sources and then upgrade back into mainline—but also allows the user to specify (with a "pin") that they prefer to continue on the alternative even if it's older.
Apt also has an "install from source" system where the source package gets baked into a binary package within a chroot container on the installing system, and then that package gets installed. That package is then like any other package on the system, and can be cleanly removed, or upgraded from into a newer upstream release, etc.
These are important features. They're not important for j-random-user, but they're important to distribution maintainers, and to sysops who have to, for example, apply temporary hotfixes to specific packages on their production machines until the distribution ships those same fixes, at which point they want to revert to upstream.
It's kind of too bad that this thread started off the way it did, because there is now a bunch of misinformation in it.
The OpenBSD ports system makes binary packages (and then installs them). Those binary packages are managed by the pkg_* tools, which allow users to install, verify, upgrade, delete, etc., packages.
The binary packages are available on the mirrors if you don't want to compile them yourself. You just 'pkg_add <package>' and you're good to go. This is actually the recommended procedure, and users are discouraged from using ports unless they really need to.
> Apt knows how to consume variant packages from alternate sources and then upgrade back into mainline...
If someone else builds a package (mtier, for example), then you can install that package from them, and then upgrade later to a newer / different version of the same package from someone else later. You can have as many package sources as you want just by adding them into the PKG_PATH environment variable.
If you want to build a custom version of a package - in the event that you somehow need one - then you can do that. This is equivalent to modifying the port, which you would do if you were personally updating the port to a new version (before the maintainer did it for you), or adding a new variant, or patching the port in some way. The resulting custom package can generally substitute for the 'official' package, so long as you haven't somehow broken it. If the mainline port is then updated, you can upgrade to it without issue.
If you don't want to upgrade a particular package, then just don't upgrade it - the system will not complain at you unless some other package eventually requires the newer version.
> Apt has an "install from source" system
Building from ports is literally building a package from source. The resulting package is the same as every other package, and will even be signed with your own package signing key (if you set that up). It can be cleanly removed, upgraded, etc., just like everything else.
The OpenBSD packages system is pretty great, and I've used apt. I personally find the pkg_* tools easier to use and more transparent than apt-*/dpkg, but I am sure this just boils down to familiarity. YMMV.
Admittedly, I just have a vague sysop-level knowledge of apt (I've made a few Ubuntu PPAs, etc.), and have also never used the BSD tooling. So thank you for correcting my misinformation.
On the other hand, AFAIK, my "misinformation" is also the "common wisdom" in the Linux sphere on the subject. So I guess I have (unintentionally) used the "Linux can't do X" (or in this case, BSD can't do X) rhetorical trick to prod you into providing the hard facts that were needed in this conversation.
I'm not sure whether I feel bad about doing that. I guess I could have couched my assertions about apt in "so this is what I believe"s. Basically, the reverse of a "this is what I hear you saying, am I understanding you correctly" statement—instead, something more of a "this is what 'my' side is taking as axiomatic assumptions, I think; I'll list mine, and you can list yours, and then we can have a discussion without implicit knowledge." Feels very much like http://lesswrong.com/lw/np/disputing_definitions/, when I put it that way.
"You can have as many package sources as you want just by adding them into the PKG_PATH environment variable."
This is great! I didn't know this was possible, and it's been one of my biggest complaints about ports on FreeBSD (I don't know if FreeBSD supports something similar now, but it didn't as recently as a few years ago).
Apologies for starting the thread off with some misinformation and seemingly incorrect negativity. I have had many, many, very bad experiences with ports, mostly on FreeBSD. I made some assumptions that OpenBSD ports was equivalent to FreeBSD ports. I also based my comments on out-dated information.
Sorry, I really don't want to talk badly about apt. I don't think it's a bad system, but all the examples you gave are things where people tend to run into horrible problems, things that wouldn't have happened if they used ports.
I don't think I completely understand the second statement. Sounds like a system like poudriere and similar to me. Also you can do the same on per-port basis. I do that, for example when I want to install a package that got released a minute ago I simply update the like that has the package version with the new one and install it. This works out great. That package is then like any other package on the system, and can be cleanly removed, or upgraded from into a newer upstream release, etc.
Especially on edge cases ports and packages seem to work way better than yum/apt, cause the complexity and the number of things that break is lower. Also how packages work is easily comprehensible (something I always enjoyed about Arch Linux too). This isn't exactly true for .deb or .rpm.
Hotfixes are another great example where ports are superior. As described above the formats in which ports are described are incredibly easy compared to how things work in the RPM/DEB world. We don't have many sysop people at our company, so time for that is precious. Using FreeBSD and its ports system actually reduced the overhead on package-related stuff a lot.
not really a favorite poet, but a favorite poem : 'Cat in an empty apartment'
Die--you can't do that to a cat.
Since what can a cat do
in an empty apartment?
Climb the walls?
Rub up against the furniture?
Nothing seems different here
but nothing is the same.
Nothing's been moved
but there's more space.
And at nighttime no lamps are lit.
Footsteps on the staircase,
but they're new ones.
The hand that puts fish on the saucer
has changed, too.
Something doesn't start
at its usual time.
Something doesn't happen
as it should.
Someone was always, always here,
then suddenly disappeared
and stubbornly stays disappeared.
Every closet's been examined.
Every shelf has been explored.
Excavations under the carpet turned up nothing.
A commandment was even broken:
papers scattered everywhere.
What remains to be done.
Just sleep and wait.
Just wait till he turns up,
just let him show his face.
Will he ever get a lesson
on what not to do to a cat.
Sidle toward him
as if unwilling
and ever so slow
on visibly offended paws,
and no leaps or squeals at least to start.
-- Wislawa Szymborska
A big locomotive has pulled into town,
Heavy, humungus, with sweat rolling down,
A plump jumbo olive.
Huffing and puffing and panting and smelly,
Fire belches forth from her fat cast iron belly.
Poof, how she's burning,
Oof, how she's boiling,
Puff, how she's churning,
Huff, how she's toiling.
She's fully exhausted and all out of breath,
Yet the coalman continues to stoke her to death.
Numerous wagons she tugs down the track:
Iron and steel monsters hitched up to her back,
All filled with people and other things too:
The first carries cattle, then horses not few;
The third car with corpulent people is filled,
Eating fat frankfurters all freshly grilled.
The fourth car is packed to the hilt with bananas,
The fifth has a cargo of six grand pi-an-as.
The sixth wagon carries a cannon of steel,
With heavy iron girders beneath every wheel.
The seventh has tables, oak cupboards with plates,
While an elephant, bear, two giraffes fill the eighth.
The ninth contains nothing but well-fattened swine,
In the tenth: bags and boxes, now isn't that fine?
There must be at least forty cars in a row,
And what they all carry -- I simply don't know:
But if one thousand athletes, with muscles of steel,
Each ate one thousand cutlets in one giant meal,
And each one exerted as much as he could,
They'd never quite manage to lift such a load.
First a toot!
Then a hoot!
Steam is churning,
Wheels are turning!
More slowly - than turtles - with freight - on their - backs,
The drowsy - steam engine - sets off - down the tracks.
She chugs and she tugs at her wagons with strain,
As wheel after wheel slowly turns on the train.
She doubles her effort and quickens her pace,
And rambles and scrambles to keep up the race.
Oh whither, oh whither? go forward at will,
And chug along over the bridge, up the hill,
Through mountains and tunnels and meadows and woods,
Now hurry, now hurry, deliver your goods.
Keep up your tempo, now push along, push along,
Chug along, tug along, tug along, chug along
Lightly and sprightly she carries her freight
Like a ping-pong ball bouncing without any weight,
Not heavy equipment exhausted to death,
But a little tin toy, just a light puff of breath.
Oh whither, oh whither, you'll tell me, I trust,
What is it, what is it that gives you your thrust?
What gives you momentum to roll down the track?
It's hot steam that gives me my clickety-clack.
Hot steam from the boiler through tubes to the pistons,
The pistons then push at the wheels from short distance,
They drive and they push, and the train starts a-swooshin'
'Cuz steam on the pistons keeps pushin' and pushin';
The wheels start a rattlin', clatterin', chatterin'
Chug along, tug along, chug along, tug along! . . . .
From  I get that PHK decided not to use privilege separation because it's not portable enough. AFAIK that's one of the main differences between OpenNTPD and Ntimed. Well, that and precision of course. OpenNTPDs accuracy is "only" around milliseconds  (which is probably good enough for anyone not using dedicated time hardware like a stratum server). The portable version missed the frequency adjustment code for years, but recently this has been added to the portable version as well.
I've also read a discussion with PHK somewhere that he didn't like OpenNTPD because it had no auth (sorry, can't find the source again). I guess this complaint has been mitigated recently now that TLS auth is supported in OpenNTPD .
/edit: not sure if it's clear but I was comparing OpenNTPD to Ntimed. But the named differences still exist when compared to ntp4.
> I've also read a discussion with PHK somewhere that he didn't like OpenNTPD
> because it had no auth (sorry, can't find the source again). I guess this
> complaint has been mitigated recently now that TLS auth is supported in
> OpenNTPD .
That's a completely new invention. It is not compatible with the NTP auth as specified in NTPv4 which uses a public key mechanism to ensure the NTP packets are not being spoofed.
Instead, this is just pointing your NTP server at an HTTPS server you trust so it can use the timestamps returned in the TLS packets as another highly trusted time source to make sure spoofed NTP packets can't skew your time. It's clever, that's for sure.
ntimed is a weird project IMO, because it's not different enough from OpenNTPD: both are small NTP daemons written in C. He could've created a fork of OpenNTPD with more precision and without privilege separation instead.
If ntimed was written in Rust though... THAT would've been excellent.
probably a legacy from stardivision, the german makers of the original staroffice, which became openoffice.org, which in turn became libreoffice. it's origins go back to when the z80 was a 'current' processor :)
This is what is interesting about LibreOffice. It's a thirty-year-old C++ codebase. Computers now have 100,000 times the memory and 1,000,000 times the CPU! And this codebase has had mediocre commercial coders working on it out of public view and following the hairpin turns of marketing. And commenting in German, because they were substantially in the StarDivision office. It's very messy.
But it's an actual product that, for all that, basically works. And millions of real people do real work with it every day.
I find Michael Meeks' tech reports really interesting, because they show how on earth a small band of very high-calibre software engineers can possibly maintain a several-million-line codebase with far too few people.
The answer is automation, directing slogging through. Unit tests, automatic code checkers, Coverity, clang plugins, assorted torture tests ...
It's a useful example of how too few people can effectively maintain and develop a huge codebase. This is knowledge the world will need for the future, as software continues to expand as absolutely large as it can.
Well, the OTHER useful example is STEPS project of the VPRI institute which claims that you could build the equivalent of our modern desktop software which much, much less code.
The big issue with this project is that AFAIK no code is available..
But it could be an interesting way: maintain an existing enormous codebase and build from scratch in parallel another one, then meet at the middle.