Requests for -current (14.2-->15.0)

individual · 08-29-2018, 08:45 AM

Quote:

Originally Posted by mina86

This is just elitism. No, Eric, using Slackware does not make you smarter than people who use other distributions. If a user cannot install Slackware from the latest stable release ISO because that release does not support their hardware, that’s not failure of the user; that’s a failure of Slackware.

I don't want to get too off-topic, nor do I want to start a flame war, but I disagree that Eric's opinion is elitism. That opinion holds true for other things as well. Here's an example: I primarily write code in C (not really). One day I decide I'll start writing code in Ruby, but I'm admittedly lazy and don't feel like learning Ruby's idioms. I try to write a block of code as I would in C, but it doesn't work, or performs sub-optimally. I blame Ruby for not supporting that way of writing that particular block and think it is a bad language.

So is it Ruby's fault for not supporting a particular way of doing something, or is it my fault for not learning "the Ruby way?" I think that is what Eric means when he says he has no patience for people "who have no time" to learn Slackware properly.

Didier Spaier · 08-29-2018, 09:00 AM

Quote:

Originally Posted by volkerdi

While I do plan to make some use of the UUID detection method, I found that many of the fdisk programs on Linux don't properly create the standardized UUID for an EFI System Partition. In particular, gdisk (which is recommended in README_UEFI) does not, while fdisk and cfdisk do follow the standard.

I am puzzled. I just tested (admittedly with a very limited scope) fdisk and cfdisk (both with dos as well as gpt disklabels), gdisk and cgdisk as well as parted (but parted doesn't allow to explicitly set the partition type so is useless in this case: only the future file system can be set and not surprisingly this leads to the partition GUID associated to a "Microsoft data partition" if set to fat32). I have not tested sfdisk and sgdisk yet.

I tested with a small USB stick fully zeroed with dd before each try, and checked the results with lsblk.

The summary of the test results is reproduced below:

Code:

# Results with gdisk:
root[/home/didier]# lsblk -l -o vendor,model,name,uuid,partuuid,parttype,size,fstype|grep sdd
LEXAR    JUMPDRIVE        sdd                                                                                                                 123.5M 
                          sdd1                                      8f8b5f16-7c72-43ee-8a23-c604c64736d9 c12a7328-f81f-11d2-ba4b-00a0c93ec93b 122.5M
# Results with cgdisk:
root[/home/didier]# lsblk -l -o vendor,model,name,uuid,partuuid,parttype,size,fstype|grep sdd
LEXAR    JUMPDRIVE        sdd                                                                                                                 123.5M 
                          sdd1                                      1fab107e-2fcf-437c-b897-f69f435bfe1e c12a7328-f81f-11d2-ba4b-00a0c93ec93b 122.5M 
# Results with fdisk, disklabel gpt
root[/home/didier]# lsblk -l -o vendor,model,name,uuid,partuuid,parttype,size,fstype|grep sdd
LEXAR    JUMPDRIVE        sdd                                                                                                                 123.5M 
                          sdd1                                      f51ba931-f55f-443e-98b7-e38ba982db81 c12a7328-f81f-11d2-ba4b-00a0c93ec93b 122.5M 
# Results with fdisk, disklabel dos
root[/home/didier]# lsblk -l -o vendor,model,name,uuid,partuuid,parttype,size,fstype|grep sdd
LEXAR    JUMPDRIVE        sdd                                                                                                                 123.5M 
                          sdd1                                      8e06346d-01                          0xef                                 122.5M 
# Results with cfdisk, disklabel gpt
root[/home/didier]# lsblk -l -o vendor,model,name,uuid,partuuid,parttype,size,fstype|grep sdd
LEXAR    JUMPDRIVE        sdd                                                                                                                 123.5M 
                          sdd1                                      43a9f6cb-b59d-4e83-a28b-54e3a5307811 c12a7328-f81f-11d2-ba4b-00a0c93ec93b 122.5M
# Results with cfdisk, disklabel dos
root[/home/didier]# lsblk -l -o vendor,model,name,uuid,partuuid,parttype,size,fstype|grep sdd
LEXAR    JUMPDRIVE        sdd                                                                                                                 123.5M 
                          sdd1                                      f2e72d05-01                          0xef                                 122.5M 
# Results with parted (FSTYPE declared: FAT32)
root[/home/didier]# lsblk -l -o vendor,model,name,uuid,partuuid,parttype,size,fstype|grep sdd
LEXAR    JUMPDRIVE        sdd                                                                                                                 123.5M 
                          sdd1                                      507eddee-381b-4461-9cdc-289399ddf17f ebd0a0a2-b9e5-4433-87c0-68b6b72699c7   122M 
# Note for parted: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 is the partition GUID for Microsoft Data Partitions, associated  by parted to FAT32 although
# no file system has been created.
# Not tested: sfdisk, sgdisk.

The UEFI specification states that an EFI System partition has a GUID of C12A7328-F81F-11D2-BA4B-00A0C93EC93B for a GPT layout; and that in case of a DOS layout instead, an ESP should have an OS type of 0xEF. lsblk writes these values in the same field PARTTYPE.

As you can see, parted put aside, all tests done show the good partition type or OS type, thus lsblk could be used to find the EFI partitions, if I am not mistaken. That's what I do in EFI3M:

Code:

ESPPARTTYPE=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
OSTYPE=0xEF
list_the_ESP() {
    # List the accessible EFI system partitions or ESPs
    lsblk -l -o name,parttype,uuid,pkname|\
    grep -i -F -e "$ESPPARTTYPE" -e "$OSTYPE"|sed "s/ \{1,\}/ /g" > $ESPLIST
    if [ ! -s $ESPLIST ]; then # No EFI partitions
        echo "No EFI partition found, game over."
        return
    fi

}

Do I miss something? Or should I made other tests, like modifying a partition table instead of creating a new one?

I attach the log of my tests with gdisk (I also installed a FAT file system and changed the partition GUID, which as expected didn't change the partition type GUID).

EYo · 08-29-2018, 09:05 AM

Quote:

Originally Posted by Alien Bob

What happened to Slackware 14.2 users who actually understand their system and are able to upgrade any software they need by compiling from source? Or even better, from the SlackBuild script provided in the Slackware-current source tree.

We are still running Grumpy Old Man Linux! I don't know that your comment was all that "helpful", I clicked because it made me LOL again. Thanks.

I'd rather not be updating a "stable" kernel every few days myself, that is not what I call stable. I don't know what Pat is planning for Current kernel versions, the updates are too frequent for my tastes.

Just in case anyone forget, I am the one who complained about a way to pay for Slackware with a paper check. I did mail it that day I commented about a month ago, but maybe the USPS has become horrible too, or the banks can't agree how to process it, or maybe Pat just hasn't taken it to a deposit station. I don't know.

My ignore list wants to grow every time I log in here lately, eternal september makes me GROUCHY so thanks LQ for cramming one useful USENET option through port 80. Cheers

nobodino · 08-29-2018, 09:12 AM

Everyone should remember there was a time when they were also rookies. I don't recommend people who don't have patience for beginners to have young children. I recon that new comers have to do some efforts, but those who have experience have to help others without contempt. If they don't have time to do it, none forces them to participate to a thread. When I don't feel competent upon a subject, I don't participate to it, nothing more. I wouldn't stay and appreciate that forum if every time I asked for an advice the answer was : RTFM, that's not my philosophy of linux, and of linuxquestions Slackware forum..

ponce · 08-29-2018, 09:36 AM

IMHO, consider also that RTFM ("reading the fine manual") more often than not can clarify issues much better than a short answer on a forum.

Alien Bob · 08-29-2018, 10:20 AM

Quote:

Originally Posted by EYo

I'd rather not be updating a "stable" kernel every few days myself, that is not what I call stable. I don't know what Pat is planning for Current kernel versions, the updates are too frequent for my tastes.

Slackware-current is not a "stable release". Frequent kernel updates are part of getting the next release to a stable state. If you don't like those frequent kernel updates you can simply blacklist the kernel packages and stick with one of the older kernels. You could also consider reverting to Slackware 14.2 to get back a feeling of stability.

Have you ever observed frequent releases of new kernels in any stable release of Slackware? Indeed, no.

Alien Bob · 08-29-2018, 10:24 AM

Quote:

Originally Posted by nobodino

Everyone should remember there was a time when they were also rookies. I don't recommend people who don't have patience for beginners to have young children. I recon that new comers have to do some efforts, but those who have experience have to help others without contempt. If they don't have time to do it, none forces them to participate to a thread. When I don't feel competent upon a subject, I don't participate to it, nothing more. I wouldn't stay and appreciate that forum if every time I asked for an advice the answer was : RTFM, that's not my philosophy of linux, and of linuxquestions Slackware forum..

In fact, I am very patient with rookies/newbies in Slackware. As long as they show a willingness to learn and are doing their own research in addition to getting answers to their questions in this forum and other places. Look back at my older posts, check out the comment sections of my blog posts. People who ask intelligent questions get a relevant answer. People who act stupid get what they ask for.

I suppose you read my post entirely the wrong way. I was referring to those new users of Slackware who do not have the patience to learn about the OS they switched to and instead want everything to "just work". Slackware is not for that category of people.

PROBLEMCHYLD · 08-29-2018, 10:29 AM

Quote:

Originally Posted by nobodino

Everyone should remember there was a time when they were also rookies. I don't recommend people who don't have patience for beginners to have young children. I recon that new comers have to do some efforts, but those who have experience have to help others without contempt. If they don't have time to do it, none forces them to participate to a thread. When I don't feel competent upon a subject, I don't participate to it, nothing more. I wouldn't stay and appreciate that forum if every time I asked for an advice the answer was : RTFM, that's not my philosophy of linux, and of linuxquestions Slackware forum..

I appreciate this post.

upnort · 08-29-2018, 10:51 AM

Quote:

However it could help to provide from time to time (maybe half yearly or yearly) a new ISO, that would just be "the current state of the stable release", i.e. with all updates provided in /patches since the last release and possibly an update of the installer.

I like this idea. Perhaps each new ISO could be called something like 14.2-1, 14.2-2, etc. I think this idea ties well into Pat's request for suggestions.

I maintain a local repo of the Slackware mirrors. I created a shell script that creates a new ISO that includes the /patches tree. I update the ISO image when my local repo updates. With respect to new installation though, there is no option to "slip stream" the /patches packages directly into the installation. If I performed a fresh install this way I would have the /patches packages handy but would need to manually install.

If Pat decided to support incremental ISO images for the stable release then an automatic method is needed to install the /patches packages. Just my two pennies.

Quote:

The whole discussion about service packs is just beating around the bush of the real elephant in the room: Slackware 14.2 has been released two years ago.

Debian has an approximate three year cycle. Ubuntu five year. Red Hat and Suse 10 year. Before Windows 10 I think the release cycle averaged about three years.

Two years might seem long compared to previous Slackware release cycles, but operating systems are now far more complex and expected to provide far more features. I like slow changes. I also expect Pat to have a life outside of Slackware. For me, Pat's development pace is just fine.

If I wanted bleeding edge or rolling release I would use Current. Or something like Arch or Fedora. Or compile all of my own packages.

upnort · 08-29-2018, 11:12 AM

Quote:

This is just elitism.

Sadly, there is a long history of elitism and RTFM in the Slackware community. Old time Slackers might recall the usenet list. That was a cruel and harsh place for any Slackware newcomer.

That mantra about the "Slackware Way" long ago got old and tiresome. Monkeys throwing poop, etc.

Where I work I don't have to often deal with the customers, but quite often I watch those in the company who do. The customers are, generally, overwhelmingly non technical and computer illiterate. I am amazed with the utter patience offered by the employees who deal with the customers. So much so that I am somewhat ashamed at my own impatience. Most of the customers are good decent people. Smart and intelligent and knowledgeable about other topics. Moms, dads, grandmas, grandpas. Just ordinary people. They are just not into computers. When I observe the other employees working with customers I wonder what happened to my own compassion for fellow humans.

I would never dream of treating children with such an attitude. Yet in this forum contempt is deemed okay when dealing with people new to computers or Slackware.

Recently there was a flurry of suggestions from many people wanting to help Pat with suggestions. Perhaps one of the suggestions could be to leave elitist attitudes at the door. Such attitudes likely are a contributing reason Slackware has declined in popularity.

Quote:

Slackware is not for that category of people.

Those of us who like to tinker "under the hood" with respect to computers are now, very much, a distinct minority. We no longer are the norm as we once were in the original heyday of computers. The remainder of the population want computers that are easy to use, no questions asked. Slackware is usable by those of us who tinker, but is not usable but the mainstream population.

Many of the suggestions offered the past many weeks are about nudging Slackware toward mainstream usage. Understandably, such suggestions tend to upset some Slackware users.

I like the overall Slackware design. Yet if Pat -- in his open plea for suggestions -- wants to target computer enthusiasts only then that message should be clear on the Slackware web site. If Pat wants to target non technical or enterprise users -- to which he hinted the possibility, then changes are needed with Slackware. Slackware as-is cannot satisfy the requirements or expectations of such users. I'll keep using Slackware one way or another. I just think Pat should be clear about the target audience so there is no confusion.

Didier Spaier · 08-29-2018, 11:59 AM

Quote:

Originally Posted by upnort

If Pat decided to support incremental ISO images for the stable release then an automatic method is needed to install the /patches packages. Just my two pennies.

Instead, in the incremental ISO, just replace the packages in /slackware or /slackware64 by those in /patches, case occurring. Just my 0.02 €

ivandi · 08-29-2018, 12:17 PM

Quote:

Originally Posted by upnort

I just think Pat should be clear about the target audience so there is no confusion.

Nah, he'll wait for another hole in his roof. Slacking is addictive

Cheers.

upnort · 08-29-2018, 01:35 PM

Quote:

Instead, in the incremental ISO, just replace the packages in /slackware or /slackware64 by those in /patches, case occurring.

Yes, of course.

But raises a question: Does the /patches directory still need to be populated (duplicated)? The change log explicitly identifies the patched packages by directory (patches/packages/*). That's somewhat why I suggested the installer be modified to install the /patches packages. No "slip streaming" involved and the user gets the latest packages installed locally rather than from online.

Which raises another point. The /patches directory always has been real-time. That is, only the most recent version of a patched package is included. Although rare, occasionally somebody needs to revert a patched package update. Currently Slackware provides no easy method to support that, which is important for enterprise users.

I have worked around this shortcoming because my backup strategy includes the /patches directory but not the remainder of my local repo mirror. I can rebuild my local repo mirror with rsync, but not the older /patches packages. I started this practice many years ago because of an obtuse bug in the Samba package that killed my connections. A fresh upstream Samba package arrived in a couple of days but during the interim I had to scramble to find the previous package version.

This is not an unknown challenge. Several times Pat has reverted packages in Current because something breaks.

Perhaps the main Slackware repo could be modified to retain older /patches packages in /pasture. Perhaps /pasture/patches? That also would include kernel packages.

I think only yum supports a direct way to reverse package history. I support CentOS at work and do not particularly care for the distro, but this reversal feature is valuable. Even the venerable Debian provides no such reversal mechanism. If replaced packages are stored somewhere in the master repo such as /pasture, at least users have a way to restore that rare botched update. Or, when bisecting bugs, have a way to easily find older packages.

If such an idea was adopted, slackpkg and slapt-get could be modified to support reverting packages to a previous version. Some sweat equity involved for all of us to test such a feature, but I think this would be much welcomed by many people.

montagdude · 08-29-2018, 01:45 PM

Quote:

Originally Posted by upnort

Which raises another point. The /patches directory always has been real-time. That is, only the most recent version of a patched package is included. Although rare, occasionally somebody needs to revert a patched package update. Currently Slackware provides no easy method to support that, which is important for enterprise users.

Can't you just set DELALL=off in /etc/slackpkg/slackpkg.conf?

upnort · 08-29-2018, 02:19 PM

Quote:

Can't you just set DELALL=off in /etc/slackpkg/slackpkg.conf?

That might be a sane starting point, but the option affects only the local slackpkg cache. Doesn't help slapt-get users, users who only use the base package tool commands, or users searching the mirrors for older packages.