The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1036 »

wooger: Apr 16, 2005; YOU RESENT?

Thermopyle posted:

Is there any reason to use Arch that isn't better served by another distro? (besides the inertia of what you're used to)

It's really just about having access to the very latest versions of any random packages, either from their main repos or in the AUR, regardless of license.

And you avoid the need to google and scrape around for random PPAs / yum repos.

Convenience over freedom / elegance / possibly safety.

One good example - before Netflix moved to html5, it used silverlight.

Under Arch there was an AUR package that downloaded silverlight, a patched version of wine and set it all up to work in Firefox. AKA pipelight.

It was much more tedious to get working on other distros.

Another example - Fedora don't package Chromium (for good reasons).

Also, their wiki is really good, and rapidly becoming the go to resource when setting up a new package regardless of distro.

Vanilla packages and systemd mean that most instructions translate well. Its odd that this distro has better documentation (for me) than the ones maintained by corporations.

Fedora has pretty up-to-date packages (never used rawhide) but to set up a system with nvidia driver, flash, Chromium, requires finding vague references to yum repos for them and tracking down instructions across various sites.

# ? May 18, 2015 09:01

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 21:56

evol262: Nov 30, 2010; #!/usr/bin/perl

wooger posted:

One good example - before Netflix moved to html5, it used silverlight.

Under Arch there was an AUR package that downloaded silverlight, a patched version of wine and set it all up to work in Firefox. AKA pipelight.

It was much more tedious to get working on other distros.

Fedora can't do this kind of stuff because we're incorporated in the US

But the AUR in general is a great illustration of my problem with arch. "Arch is vanilla!" But the AUR is patched to hell. Instead of patching packages and putting a patched version in the AUR to do something the mainline/vanilla version doesn't, why not submit those patches upstream? They might get rejected or a bad code review, but you can always resubmit, and that happens to full-time project developers as well.

wooger posted:

Another example - Fedora don't package Chromium (for good reasons).

The reason chromium/chrome isn't officially packaged is bad and we all agree it's bad (it's also a problem with spotify, steam, rust, and a few other tools that ship statically linked binaries or their own versions of them). It made sense 8 years ago. It doesn't now.

wooger posted:

Also, their wiki is really good, and rapidly becoming the go to resource when setting up a new package regardless of distro.

I'd disagree with this just because many distros ship with a working configuration out of the box. But statements like "rapidly becoming the go to" are unverifiable. Personally, I can count on one hand the number of times I've found the arch wiki better or more useful than "man some.conf" or the project's documentation on github or wherever. The arch wiki is very good about stuff like EFI, but that's also the kind of stuff the average user just shouldn't need to worry about or deal with.

"Here's instructions for how to fix our broken by default package" or "when updating to foo-1.2.3, this breaks, here's how to fix it" are the kind of things that get bugs filed on other distros. Opaque bits get RFEs filed to make better defaults, better documentation, or a better interface.

The arch wiki can be useful in some sense, but, personally, I feel that it's an "old" way of doing things that deters people from using Linux and adds complexity for no gain. But I feel that way about the entire arch community, I guess.

wooger posted:

Vanilla packages and systemd mean that most instructions translate well. Its odd that this distro has better documentation (for me) than the ones maintained by corporations.

If you ever get a chance, you really should read the official fedora docs, or freebsd's. Arch has better community documentation and it's ranked higher on google. I'm not at all sure whether it's better. It's good, and I'm sure it beats the official docs in some places (as do the Ubuntu forums and wiki), like "how do I set up samba to be an AD server with group policy", but fails in some places (like iptables). It's a mixed bag.

wooger posted:

Fedora has pretty up-to-date packages (never used rawhide) but to set up a system with nvidia driver, flash, Chromium, requires finding vague references to yum repos for them and tracking down instructions across various sites.

Arch basically repackages the same stuff as rawhide and suse factory.

Fedora is a bad example here because we're in the US and we can't redistribute some software officially. But "nvidia+flash" is one incredibly common repo. Google officially packages chrome and hosts a repo. Literally the first result for chromium+fedora is a link to the wiki page, which has a repo.

But compare to suse factory, which packages all those things, has similar package versions to arch, and is relatively vanilla. What's the advantage?

# ? May 18, 2015 14:57

reading: Jul 27, 2013

Did Netflix finally switch to HTML5? Because I still can't use it on Linux (Xubuntu).

Question: Is there a utility that scans your system for any files with permissions set to 777 and lists them so that one can do a security audit of one's system? In the past I played pretty fast and loose with sudo chmod 777 because I didn't understand chown or chmod +x and I'd like to go through and take a second look at any system files I left laying around with 777.

# ? May 18, 2015 18:50

evol262: Nov 30, 2010; #!/usr/bin/perl

reading posted:

Did Netflix finally switch to HTML5? Because I still can't use it on Linux (Xubuntu).

Question: Is there a utility that scans your system for any files with permissions set to 777 and lists them so that one can do a security audit of one's system? In the past I played pretty fast and loose with sudo chmod 777 because I didn't understand chown or chmod +x and I'd like to go through and take a second look at any system files I left laying around with 777.

find / -type f -perm 0777

# ? May 18, 2015 18:52

reading: Jul 27, 2013

evol262 posted:

find / -type f -perm 0777

Thanks!

Different question: Why are folders 4.0kB (I think I'm using exFAT)? If a folder in the linux filetree is just a file that consists of links to all the files "in" it, then why doesn't the size change based on the number of files "in" it that it has to link to?

# ? May 18, 2015 19:00

Not Wolverine: Jul 1, 2007

reading posted:

Did Netflix finally switch to HTML5? Because I still can't use it on Linux (Xubuntu).

Question: Is there a utility that scans your system for any files with permissions set to 777 and lists them so that one can do a security audit of one's system? In the past I played pretty fast and loose with sudo chmod 777 because I didn't understand chown or chmod +x and I'd like to go through and take a second look at any system files I left laying around with 777.

Just covering the basics, what browser are you using? It should work by default in Chrome, I suspect you might need to install additional packages to make it work in Chromium. I used to watch Netflix in Linux by using Firefox (with user agent string set to Windows) and a wine wrapper for silverlight, I think the package was called pipelight.

reading posted:

Thanks!

Different question: Why are folders 4.0kB (I think I'm using exFAT)? If a folder in the linux filetree is just a file that consists of links to all the files "in" it, then why doesn't the size change based on the number of files "in" it that it has to link to?

File system block size. Someone else can probably explain this better (like the reason for why it's done) but modern file systems don't try to address every last bit of a hard drive individually, they group them into blocks also known as chunks, clusters, pages, etc. I believe it provides better performance when using the file system but that is the part I don't know a lot about.

4KB is the default size for exFAT and I am a bit surprised you are using exFAT, unless the file system in question is a flash drive?

Not Wolverine fucked around with this message at 19:11 on May 18, 2015

# ? May 18, 2015 19:02

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

reading posted:

Did Netflix finally switch to HTML5? Because I still can't use it on Linux (Xubuntu).

They didn't really "switch"; Netflix has supported both HTML5 in addition to the Silverlight player for about eight or nine months now. HTML5 requires Chrome (not Chromium), though I think Firefox's support of HTML5 DRM is really close to working in the latest release. If your version of Chrome was upgraded from something really old, you might need to visit chrome://components and update WidevineCdm.

# ? May 18, 2015 19:05

evol262: Nov 30, 2010; #!/usr/bin/perl

Crotch Fruit posted:

File system block size. Someone else can probably explain this better (like the reason for why it's done) but modern file systems don't try to address every last bit of a hard drive individually, they group them into blocks also known as chunks, clusters, pages, etc. I believe it provides better performance when using the file system but that is the part I don't know a lot about.

Block size is the right answer.

reading posted:

Different question: Why are folders 4.0kB (I think I'm using exFAT)? If a folder in the linux filetree is just a file that consists of links to all the files "in" it, then why doesn't the size change based on the number of files "in" it that it has to link to?

A folder in the linux file tree (or NTFS file tree, or FAT, or whatever) isn't a file that contains a list of all the links.

Everything is represented as C data structures. inodes, dentrys, and vfsmounts. A directory is a special instance of a file, but that doesn't mean it literally is a "file" in the text file sense with a list of children. Those are looked up by walking data structures.

# ? May 18, 2015 19:29

ExcessBLarg!: Sep 1, 2001

Crotch Fruit posted:

File system block size.

Often there's a difference between the reported size of a file and the amount of actual file system (disk) space that it uses. For regular file, the size reported by fstat (ls, stat, etc.) is pretty unambigous--it's the number of bytes that would be read if you were to open the file and read it until the end. For things like directories, the size is ambiguous, and in some ways doesn't matter, because you can't open the file and read it as a byte stream. File system drivers will typically report the amount of space consumed by some internal data structure. exFAT probably returns the total size of the clusters consumed by the directory, which would minimally be 4 kB for a single cluster.

# ? May 18, 2015 19:49

RFC2324: Jun 7, 2012; http 418

Should also point out that you can adjust the inode(block) size on quite a few filesystems, so you can have blocks smaller than 4k, or larger. Smaller size means the filesystem works harder, while a larger size means a faster filesystem, but more wasted space per file.

I've always wanted to do a root fs with a time, like 512 byte, block size, and a data filesystem for 1 meg as the block size, just to see if I can tweak and tune for perfect speed.

I can do this on a gentoo system, and have the fastest system on the block(by an un-noticable amount)

# ? May 18, 2015 21:38

CaptainSarcastic: Jul 6, 2013

reading posted:

Did Netflix finally switch to HTML5? Because I still can't use it on Linux (Xubuntu).

You might need to install the NSS package - I've had to install it on my OpenSUSE installs to get Netflix to run.

# ? May 19, 2015 04:25

Gucci Loafers: May 20, 2006; Ask yourself, do you really want to talk to pair of really nice gaudy shoes?

Anyone interested in doing a group Let's Read for RHEL 7? Note, this isn't Michael Jang's book and the reviews for this aren't as consistent but Mike's book doesn't come out until November.

Gucci Loafers fucked around with this message at 04:51 on May 19, 2015

# ? May 19, 2015 04:49

Truga: May 4, 2014; Lipstick Apathy

Vulture Culture posted:

HTML5 DRM is really close to working

Am I the only one giggling uncontrollably at this? :v:

# ? May 19, 2015 14:36

program666: Aug 22, 2013; A giant carnivorous dinosaur

actually I think there is no drm support anymore on firefox http://techcrunch.com/2015/05/12/mozilla-launches-a-new-firefox-version-without-drm-support/

# ? May 19, 2015 14:40

Prince John: Jun 20, 2006; Oh, poppycock! Female bandits?

program666 posted:

actually I think there is no drm support anymore on firefox http://techcrunch.com/2015/05/12/mozilla-launches-a-new-firefox-version-without-drm-support/

I think you might have missed the second sentence:

quote:

Today, the organization officially launched HTML5 DRM support with the release of Firefox 38. In addition, however, Mozilla also announced the launch of a separate Firefox download that won�t automatically install Adobe�s technology for playing back DRM-wrapped content in the browser.

# ? May 19, 2015 15:17

wooger: Apr 16, 2005; YOU RESENT?

evol262 posted:

If you ever get a chance, you really should read the official fedora docs, or freebsd's. Arch has better community documentation and it's ranked higher on google. I'm not at all sure whether it's better. It's good, and I'm sure it beats the official docs in some places (as do the Ubuntu forums and wiki), like "how do I set up samba to be an AD server with group policy", but fails in some places (like iptables). It's a mixed bag.

Can you link to the Fedora docs you refer to?

The only thing I've found linked from getfedora.org is this.

Which seems in a weirdly old fashioned layout, with no links between items, and not even a search box visible.

FreeBSD and OpenBSD docs are known to be well maintained, but they're not for linux, so many things don't transfer.

edit: In what way does the Arch Wiki iptables entry fail?

# ? May 19, 2015 17:34

evol262: Nov 30, 2010; #!/usr/bin/perl

wooger posted:

Can you link to the Fedora docs you refer to?

The only thing I've found linked from getfedora.org is this.

Yes, those are the docs

wooger posted:

Which seems in a weirdly old fashioned layout, with no links between items, and not even a search box visible.

These are bluntly god-awful ways to evaluate documentation. "Not even a search box is visible" because it's not a wiki. It's documentation. Like a manual. Which is topic-based, with a real index. Try looking at one of the guides, and you'll see a hyperlinked table of contents, much like a book, which everyone is familiar with and good at navigating.

The one place Fedora is bad is that not every guide is re-written every release, so you have to go look at Fedora 19 to find the security guide, for instance.

wooger posted:

FreeBSD and OpenBSD docs are known to be well maintained, but they're not for linux, so many things don't transfer.

The vast majority of software that runs on BSD is the same as Linux. The installation parts and disk management aren't useful, but the FreeBSD's sections on other stuff are miles better than Arch's. Go read some of these. If you want to do "technical" documentation, FreeBSD's are much clearer (conf files have footnotes, BIND explains all the record types, basic configurations are provided and explained, etc). Apache and FTP are pretty bad. DHCP and DNS are very good.

wooger posted:

edit: In what way does the Arch Wiki iptables entry fail?

In the same way Arch's documentation fails everywhere else, basically.

It's written for a sort-of admin who's expected to know what iptables is and familiar enough with the concepts to be presented with a chart of packet flow right off the bat, and a bunch of too-technical information right from the beginning for someone who's trying to learn about iptables. If you can get that as a user new enough to need to read a wiki page on it, you're aware of (and can read) manpages.

Terrible docs posted:

The Dropbox LAN sync feature broadcasts packets every 30 seconds to all computers it can see. If we happen to be on a LAN with Dropbox clients and do not use this feature, then we might wish to reject those packets.

# iptables -A INPUT -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable

So, this is the first really useful thing. It's copy and paste magic that only makes sense under the assumption that you, a user so unfamiliar with it that you needed to look up a wiki page, completely absorbed an entire page of relatively dense material.

Go read through this. Use the "next" button on the bottom until it isn't talking about firewall-cmd anymore. Do you see how it slowly introduces concepts and builds on them? When it shows you a command, the explanation of what's happening, in non-technical language, is 2-3 times longer?

If we go back to Fedora 18, you can read the iptables guide, which is less clear than firewall-cmd, but still slowly introduces and builds on concepts, lets you know about possible pitfalls (like rules ordering), includes notes for further explanation, etc?

archlinux.jpg is always relevant

# ? May 19, 2015 17:57

YouTuber: Jul 31, 2004; by FactsAreUseless

Did Arch Linux rape your family or something? You've been ranting for about 3-4 pages now.

# ? May 19, 2015 18:59

evol262: Nov 30, 2010; #!/usr/bin/perl

YouTuber posted:

Did Arch Linux rape your family or something? You've been ranting for about 3-4 pages now.

Someone asked for opinions on Arch. I gave mine. Someone responded. I replied. Etc.

I don't have anything against Arch. I don't think most Arch users understand how the broader Linux ecosystem works or what Arch is (AUR, wiki) isn't (contributing upstream, end-user documentation, helping you understand what's happening on your system) good at. It has definite pluses and minuses. Talking about those negative aspects isn't ranting.

# ? May 19, 2015 19:05

spankmeister: Jun 15, 2008

Arch is bad the Arch community is bad but their wiki is a good resource for people who know what they're doing and not for people who want to blindly type in commands to fix whatever their issue is.

# ? May 19, 2015 19:07

spankmeister: Jun 15, 2008

Just wanted to post that UFW is bad.

Really, really bad.

Holy moly.

# ? May 19, 2015 21:51

Truga: May 4, 2014; Lipstick Apathy

spankmeister posted:

Arch is bad the Arch community is bad but their wiki is a good resource for people who know what they're doing and not for people who want to blindly type in commands to fix whatever their issue is.

Arch wiki is to me now what Gentoo wiki used to be. A really good resource for obscure problems you'll never face on real distros, but when something breaks, at least some idiot on Arch wrote something about it so you can fix it in 5 minutes instead of taking an hour.

Speaking of which, whatever happened to Gentoo's wiki? I haven't seen it in my google results for a while now.

# ? May 20, 2015 11:45

wooger: Apr 16, 2005; YOU RESENT?

A wiki is clearly a better way to use documentation for anything, sorry.

Topic based splits as a front page index is fine, but to some extent what appears where is an arbitrary decision. If I don't know this, I need to search.

Books on a topic are fine, but you have to realise that in 99% of cases, people are looking for the solution to a problem, or for information on configuring one package.

It makes no sense to make them wade through this stuff.

Most users are not interested in learning to be a sysadmin for their own desktop, and are only even looking for documentation because something is broken. They're already pissed off without being confronted with a page that doesn't let them search it.

# ? May 20, 2015 15:37

evol262: Nov 30, 2010; #!/usr/bin/perl

wooger posted:

A wiki is clearly a better way to use documentation for anything, sorry.

This is your opinion stated as fact, sorry.

Not that I don't write that way sometimes, but it really, really is just your opinion, and we have teams of people paid to write docs. Every company I've ever worked for has technical documentation writers. Not one of them I've spoken to ever thinks a wiki is better documentation. Wikis are used internally. Docbook is used by almost every project.

wooger posted:

Topic based splits as a front page index is fine, but to some extent what appears where is an arbitrary decision. If I don't know this, I need to search.

What do you possibly think you're searching for? Random commands that you don't know?

wooger posted:

Books on a topic are fine, but you have to realise that in 99% of cases, people are looking for the solution to a problem, or for information on configuring one package.

Says somebody who isn't a doc writer. That's ok. I'm not either. But I'd agree that in 99% of cases, people are looking for information on configuring something. The difference is that you assume they can even articulate their problem or that they know what "one package" best solves their problem, how else it can be used, what else fits in that space, etc. Docbook doesn't make those assumptions.

wooger posted:

It makes no sense to make them wade through this stuff.

I'd say the same about the pile of poo poo every Arch wiki page makes you wade through, like diagrams of packet flow assaulting you first thing on babby's first firewall page.

wooger posted:

Most users are not interested in learning to be a sysadmin for their own desktop, and are only even looking for documentation because something is broken. They're already pissed off without being confronted with a page that doesn't let them search it.

I agree that most users aren't interested in learning to be a sysadmin. They are interested in following organized, easy-to-use guides for configuring common aspects of their system. Does this sound like the Arch wiki or the Fedora docs?

As a relatively technical user who knows how to look at a problem and find what's meaningful about the error message to pump it into Google, the Arch wiki can be great. Imagine you're a new user. I also find the Arch wiki more useful than the Fedora docs. For me. But they wouldn't be for almost any "normal" (if Linux gets to a point where "normal", relatively non-technical users start making up more of the userbase). Linux user I can think of.

evol262 fucked around with this message at 16:12 on May 20, 2015

# ? May 20, 2015 16:09

OnymousCoward: Feb 19, 2014

Wikis and man pages are both pretty cool and useful, they're just useful for different things is all.

Wikis are better if you generally know what you're doing, man pages are better for if you need to do something and don't know what you're doing.

They both have their place, is what I'm saying.

# ? May 20, 2015 16:18

wooger: Apr 16, 2005; YOU RESENT?

OnymousCoward posted:

Wikis and man pages are both pretty cool and useful, they're just useful for different things is all.

Wikis are better if you generally know what you're doing, man pages are better for if you need to do something and don't know what you're doing.

They both have their place, is what I'm saying.

That is entirely reasonable.

It's important to note that content and presentation can be separate things;

There's no reason a wiki article couldn't be stripped down to text and be displayed just like a man page, or vice-versa.

Really a man page is limited by it's medium - getting away from that requirement (e.g. for access via a web browsers), there's no obvious reason why the same exact man page content couldn't be displayed like a wiki article, with links inserted for terms with their own man page, some nice CSS etc. No need to make it user-editable of course.

I'd bet there's probably something on CPAN to build this from a directory structure already.

However, I'm not sure I can believe that a search box is so controversial - literally every web page and every app I have open at present has one visible (SA excepted).

# ? May 20, 2015 17:38

evol262: Nov 30, 2010; #!/usr/bin/perl

wooger posted:

Really a man page is limited by it's medium - getting away from that requirement (e.g. for access via a web browsers), there's no obvious reason why the same exact man page content couldn't be displayed like a wiki article, with links inserted for terms with their own man page, some nice CSS etc. No need to make it user-editable of course.

info isn't limited that way, and works pretty much the way you describe. of course it uses emacs keybindings, but...

wooger posted:

However, I'm not sure I can believe that a search box is so controversial - literally every web page and every app I have open at present has one visible (SA excepted).

I don't think it's that having a search box is controversial. Having a search box is fine. But having/not having a search box doesn't make documentation better/worse. The fedora docs would be better with a searchbox. But the argument is basically that docbook is still a better end-user documentation format than a wiki. Documentation is for instruction, not troubleshooting. The "troubleshooting" section of any book or documentation is generally in an appendix somewhere (including in all the manuals for every appliance you've ever purchased, etc), and refers you to somewhere you can find more information on troubleshooting... whatever.

You can strike a middle ground. The Arch Installation Guide has a table of contents, sort of, but the installation guide is terrible. The beginner's guide is somewhat better, and also has a table of contents.

But the Gentoo Handbook is excellent in that regard. It has a clearly topic-based table of contents, which links down to individual pages (which are probably wiki, but I've never looked), using the same "Back | Home | Forward" semantics that have proven to work very well.

# ? May 20, 2015 18:19

Shaocaholica: Oct 29, 2002; Fig. 5E

Will a binary executable built for Fedora run on RHEL? Not sure how many different platforms get coverage with Linux binaries.

# ? May 20, 2015 21:29

MrMoo: Sep 14, 2000

The glibc version has to match, then you can usually find any dependent libraries, static linking removes that as a problem though.

# ? May 20, 2015 21:37

evol262: Nov 30, 2010; #!/usr/bin/perl

Shaocaholica posted:

Will a binary executable built for Fedora run on RHEL? Not sure how many different platforms get coverage with Linux binaries.

Maybe.

It's not about "platforms" getting coverage. It's whether or not the dynamic linker can resolve the dependencies in the ELF header, meaning "does this system have libraries which match what the binary expects to find", and even then you may find missing symbols and hard to debug crashes. It depends on which version of Fedora and which version of RHEL, when they branched, and whether or not the libs resolve.

Try putting it there and ldd-ing it. Better, get source or a srpm and rebuild it.

# ? May 20, 2015 21:38

Docjowles: Apr 9, 2009

So here's a weird one. I ended up "solving" it with a reboot since it was a production box that needed to get fixed, but would love to know if there is anything else I could have done.

Java app (Tomcat) is not accepting requests on TCP port 8085 anymore. I kill Tomcat and see there's a <defunct> Java process still holding the port open. The parent of that defunct process is init, PID 1. So it should have already been reaped.

If I grep "ps" for zombie or io-blocked procs, I see it in there.

code:

Zl   14222     1 nobody   exit                      [java] <defunct>
Dl   14222     1 nobody   rpc_wait_bit_killable     [java]

I do "lsof -p 14222" and get something like this:

code:

COMMAND  PID   USER   FD      TYPE DEVICE SIZE/OFF NODE NAME
java    14222 nobody  cwd       DIR  253,0     4096    2 /
java    14222 nobody  rtd       DIR  253,0     4096    2 /
java    14222 nobody  txt   unknown                      /proc/14222/task/10544/exe (readlink: No such file or directory)

Whatever had PID 10544 is no longer running. I tried unmount a couple NFS shares, since that's really the only thing I could think of that would be blocking the IO, but it did not help.

Anything else I could have done to resolve without a reboot?

# ? May 20, 2015 22:54

fatherdog: Feb 16, 2005

wooger posted:

Most users are not interested in learning to be a sysadmin for their own desktop

Then what the gently caress are they doing using Arch?

# ? May 20, 2015 22:55

wooger: Apr 16, 2005; YOU RESENT?

fatherdog posted:

Then what the gently caress are they doing using Arch?

Well, that's kind of my point - it's used a lot by people not on Arch, as it's so useful. Google puts it at the top of many linux related queries too.

evol262 posted:

But the Gentoo Handbook is excellent in that regard. It has a clearly topic-based table of contents, which links down to individual pages (which are probably wiki, but I've never looked), using the same "Back | Home | Forward" semantics that have proven to work very well.

The Gentoo handbook looks pretty well presented, I'd agree, and is notably nicer to use than the docbook format. Also if a search for e.g. samba, I get a single page with all the samba information, with links out to other pages where appropriate. Interestingly, that result page doesn't show the back/home/forward navigation at all.

The Fedora docs frequently have a whole page with 2 sentences on it. I can't grok the need for or benefit of the weird pagination.

# ? May 21, 2015 12:32

Anarchist Mae: Nov 5, 2009; by Reene; Lipstick Apathy

evol262 posted:

I think that's an intentional design decision in the package postinstall scripts that's likely hard or impossible to change globally.

Well, they contribute nothing. Not "not much". Nothing.

Arch is about as bleeding edge as Fedora Rawhide (which is much more stable than it used to be, and more stable than Arch), with a userbase not much larger.

But the real issue is that Arch users tend to report issues on their forums, and other users (or package maintainers) give them lovely workarounds on those forums instead of reporting bugs, or, god forbid, submitting patches. They don't report bugs. They just complain. Beyond which, the vast majority of bugs fixed are in released Fedora versions/development openstack/etc (if they're obvious workflow problems that didn't get caught in CI somehow) or in LTS/EL versions if they're obscure (like "I have 175 LUNs unmasked on this HBA, and the installer only shows 100 disks -- my local disk isn't visible!"). Basically zero bug reports come from Arch or Arch users. They're ur-consumers.

Arch is the guy who shows up to your pot luck with nothing, eats all the food, drinks all the beer, complains that you have no craft beer to everyone who's attending, then goes home and writes a butthurt post on their facebook page about how your party sucked and they'd do it so much better.

If anyone here is butthurt, it's you.

# ? May 21, 2015 14:36

covener: Jan 10, 2004; You know, for kids!

Measly Twerp posted:

If anyone here is butthurt, it's you.

https://wiki.archlinux.org/InterpretingMetaphorsSoYouDontEmbarassYourself

# ? May 21, 2015 14:49

evol262: Nov 30, 2010; #!/usr/bin/perl

wooger posted:

Well, that's kind of my point - it's used a lot by people not on Arch, as it's so useful. Google puts it at the top of many linux related queries too.

It's a great troubleshooting resource, yes. But is troubleshooting documentation?

wooger posted:

The Gentoo handbook looks pretty well presented, I'd agree, and is notably nicer to use than the docbook format. Also if a search for e.g. samba, I get a single page with all the samba information, with links out to other pages where appropriate. Interestingly, that result page doesn't show the back/home/forward navigation at all.

The Gentoo Handbook could be done docbook with a different stylesheet which collates subheadings from chapters. It isn't, but they intentionally aped the way docbook navigates for the official install/config part (the handbook -- the rest of the site is the gentoo docs)

But the result page doesn't show back/home/forward because it's not the handbook.

wooger posted:

The Fedora docs frequently have a whole page with 2 sentences on it. I can't grok the need for or benefit of the weird pagination.

Yeah, they could have a better stylesheet.

Measly Twerp posted:

If anyone here is butthurt, it's you.

Thanks for that quality contribution on how the Linux ecosystem works.

# ? May 21, 2015 14:59

Anarchist Mae: Nov 5, 2009; by Reene; Lipstick Apathy

evol262 posted:

It's a great troubleshooting resource, yes. But is troubleshooting documentation?

The Gentoo Handbook could be done docbook with a different stylesheet which collates subheadings from chapters. It isn't, but they intentionally aped the way docbook navigates for the official install/config part (the handbook -- the rest of the site is the gentoo docs)

But the result page doesn't show back/home/forward because it's not the handbook.

Yeah, they could have a better stylesheet.

Thanks for that quality contribution on how the Linux ecosystem works.

Yes, because the unwarranted making GBS threads on every user of a distribution is a clear demonstration of the words "quality contribution".

# ? May 21, 2015 16:59

RFC2324: Jun 7, 2012; http 418

Measly Twerp posted:

Yes, because the unwarranted making GBS threads on every user of a distribution is a clear demonstration of the words "quality contribution".

Arch is poo poo, and is bad for Linux as a whole. Face it, and realize that its people who trumpet how good it is that make it so poo poo.

# ? May 21, 2015 17:58

evol262: Nov 30, 2010; #!/usr/bin/perl

Measly Twerp posted:

Yes, because the unwarranted making GBS threads on every user of a distribution is a clear demonstration of the words "quality contribution".

I'm sorry that you think representing the Arch userbase the way they actually act is "making GBS threads on every user". The way to rebut that is to actually rebut it, not to talk about your feelings or how you're offended.

I also think the Arch forums are useful, because they're well-indexed by Googlebot and they come up when you Google problems. But I can count the number of times I've seen anyone talk about reporting bugs on zero fingers. I can talk about the number of times I've seen anyone link to an upstream patch which resolves it on zero fingers. I can count the number of bugs that have been reported by Arch users and assigned to me on zero fingers.

It's possible that they're reporting bugs without giving details of their system (many users do, or it's apparent from the version that they're running Ubuntu or EL6 or whatever), and it's definitely not the Arch developer's fault that it's this way, because the wiki is very clear on it, with good practice. It's likely an artifact of the fact that the people who started the Arch community were mostly ex-Gentoo users (including me, years ago), and posting "foo-1.2.3 crashes when I do bar" to the forums is a fast way to see who else has seen that problem and if anyone else has resolutions. It works well, especially when your community is large and active. The downside of this is that the forums then become the canonical place to report issues and get fixes for them, and nobody bothers reporting it as a bug. And the fix is often not a real patch anyway, but some toggle or way to hack around it, so they couldn't submit a patch upstream even if they wanted to.

It's fine to be consumers. It's not a judgment. I don't care if you contribute. But don't make a lot of noise about "upstream" if you're not involved in it. Arch is still fine if you want to use it, and the forums are fine, but it's a real thing.

# ? May 21, 2015 18:34

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 21:56

midnightclimax: Dec 3, 2011; by XyloJW

Ubuntu (XFCE) is unable to switch off the screensaver when I'm running VLC. It's really annoying. I thought "caffeinate vlc" would do the trick, but no cigar. Switching off power management is kinda dumb, since it's a laptop.

# ? May 21, 2015 20:43

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1036 »