Patrick takes files where he find useful ones to build the packages. I assume that he is following practical considerations rather than sympathy. Check these links:
http://ftp.slackware.com/pub/slackwa...tools/sources/
http://ftp.slackware.com/pub/slackwa...ource.download
Regardless of the method, installing on a distribution a package intended for another one won't work but can break the system for reasons that I won't repeat once again.

But instead for a script inspired of the way Arch packages are built, check slkbuild written by George Vlahavas.

1 members found this post helpful.

The main reason of testing is testing ie. one can break something and is quite aware of this. I will test because author of the script I mentioned claims script is universal and should run everywhere. I am curious how much this claim is justified.

As long as you don't request support here to repair what this script could break that's fine, indeed.

The Linuxdoc-tools package build script uses rpm2cpio which is from the rpm package.
We use the source RPMs because it's easier for me to use Fedora as an upstream (because often this doc stuff gets broken and they fix it first), and saves me re-compressing the sources. I've always done it this way. Simple as that.

3 members found this post helpful.

Non-sequitur in the extreme. It has zero to do with Schadenfreude. I'm sure all decent people wish others to succeed BUT success is not measured only in financial return. Far more important to me, and apparently also to Patrick (it is his choice after all) is the joy and pride in a finely crafted product that deserves admiration and respect. In that IMHO he has succeeded.


Of course that would make me extremely happy since it would mean larger numbers of global population would show reason and critical thought in the area of Cost/Benefit, assuming the increase in pay came from user appreciation of his finely crafted product rather than the opposite of caving in to the lowest common denominator.

IMHO it all boils down to this, whom do you respect more and who had more impact on the history and development of Music, Salieri or Mozart?... or in more modern terms The Monkees or Jimi Hendrix?

Some people say you should judge a distro by the number of offspring forked from it, on the grounds that imitation is the sincerest form of flattery. On that basis, Debian has done very well over the years.

2 members found this post helpful.

There seems to ba an assumption that the "Market Place" is entirely and undeniably a meritocracy, the "better mousetrap > world beating path to door" natural progression. It isn't so.

If you think so ask yourself three simple questions

1) Who makes the best, most delicious, most nutritious hamburgers on Earth?

2) Who sells the most hamburgers on Earth?

3) Are they one and the same?

2 members found this post helpful.

I am sure ext4 is fine, but it was written when people mostly had conventional disks, and SSDs are an afterthought. That is my issue with majority distros, there are FSs like YAFFS, JFFS2 and F2FS, but I do not see any distro implement those for use as a /. Either maybe the FS in question just do not support it or what I don't know. I mean Slackware --Current added F2FS at least for installation which is great, I just wish there were the other options. My line of thinking is that those particular filesystems are specifically written for NAND devices, whereas ext4, XFS etc, were written during the era of conventional disks. I myself still have a conventional disk for /home and an external merely for backup, and while people are transitioning over to SSDs, conventional will still most likely be used for archival purposes as far as I see.

I recall probably because of either a technical issue with Reiser4, but then Reiser himself (prior to being arrested and convicted) stated it was political or something I dunno. I do think it is safe to say that Reiser4 is going to be completely dead in the coming years, as again stated that the user base is practically non-existent and whomever is maintaining it, will eventually just move on.

Yuck.

One of the best things about Slackware is that it's packages are simply tarred/zipped directory structures. Having the ability to create one's own packages is just one of the ways Slackware empowers its users. You can't create a package for Debian unless you're an authorized maintainer. Adopting the deb format is among the worst possible things Slackware could do.

None of these things would change anything. Dependency resolution and Debian packaging will not have the result you seem to think it would. What it will do is change Slackware into something it isn't... and at that point it will be just another pretender. As if there aren't enough of those already.

Let it be. Why is that so hard???

4 members found this post helpful.

Better is a such a relative thing though. There is usually a market space for 'inferior goods'. I might sometimes want the most delicious hamburger, there are other times when I don't have 45min to wait for it to be prepared and I just want something to scarf without getting out of my car. I am simply hungry I will be driving barely thinking about what I am even eating.

Same with Linux distros. Sometimes I want something any ape can keep running like Ubuntu to just host some web app front end. Other times I want confortable general use working environment that does not piss me off at every turn, so I pick Slackware even if it means I have to invest in some special knowledge to make it want I want it to be.

I'm not sure what difference this makes when you can unpack rpms with or unpack .debs with Anybody can make a Debian package for themselves, just as anybody can make a Slackware one.
Nobody in the Slackware community can put their packages within the Slackware distribution directly either.

1 members found this post helpful.

It is not Slackware is worse - just lack of constant timeline for stable releases makes almost impossible to run derivative. Only one thing came to my mind: rolling-release derivative on LTS kernels in -current. Of course with neccesary delay to makes things stable.

Funny, I frequently use the McDonald's example myself, in the same way.

I don't think deb2tgz ever existed in Slackware (but it is on SBo). I do stay away from deb2tgz and rpm2tgz (because of potential issues like this one). If I need to use an rpm or deb, I'll create my own script to extract the package and repackage it into a Slackware package (see my discord SlackBuild), ensuring permissions and file locations are accurate.

#1 and #2 will almost never be the same. Cost and labor will almost always ensure they never match. In distro-land, source based distros are almost always going to perform better than package based distros since the installed packages will be tailored to your hardware (the gains might be minimal, but they will most likely exist). But there is a massive cost of time involved when using a source based distro and not everyone has (or wants to spend) the time to be able to use it.

McDonalds sells the most hamburgers because they're good enough. They're cheap to buy, fast to make, and there's plenty of nearby McDonalds with convenient drive-thrus to be able to pick one up. They taste good enough for a lot of people.

I've looked into different filesystems over the years, but it seems that there still isn't a clear choice on what filesystem is best to use with NAND based devices. Yes, F2FS may have been written from the ground up to work solely with NAND, where ext4 had support for NAND added in later, however, F2FS is not a clear winner in regards to performance. In this test from Phoronix about a year ago, ext4 had better performance in 13 of the tests vs F2FS outperforming ext4 in 9 of the tests. And similar performance has been seen in previous tests as well. Maybe there's some other aspects of F2FS that might be better that I'm not aware of, but performance-wise, there's no clear winner.

(I think I remember reading that F2FS may help deal with wear-leveling, which if that is true, it would likely be beneficial on portable devices like thumbdrives or sd cards, but for SSDs or NVMe devices, the controller handles all wear-leveling, so it wouldn't help with those types of devices.)

1 members found this post helpful.

After much thought I chose for the root (/) file system to use f2fs in Auto mode during Slint installation only for flash devices firmly attached to the computer, so SD card in a built-in card reader or eMMC drives, not USB sticks or SD cards in an USB enclosure, as I have read reports of corrupted F2FS in case the USB connection be bad and I don't know to which extent this has been solved.