Quote:
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. |
1 Attachment(s)
Quote:
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: 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 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). |
Quote:
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 |
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..
|
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.
|
Quote:
Have you ever observed frequent releases of new kernels in any stable release of Slackware? Indeed, no. |
Quote:
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. |
Quote:
|
Quote:
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:
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. :) |
Quote:
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:
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. :) |
Quote:
|
Quote:
Cheers. |
Quote:
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. :) |
Quote:
|
Quote:
|
All times are GMT -5. The time now is 06:11 PM. |