Sticky post with current Linux native instructions?

Okay, not only has my memory failed me, but apparently my Google-fu is weak. I have the Linux native 1.5 beta 7 running on my Ubuntu 10.10 Maverick 64-bit install, but cannot for the life of me remember the steps, and I believe the instructions I’ve been able to re-find may be outdated. Trying to install on a VM for further testing, but my brain seems to have gone on strike.

So for people like me who tend to forget their own names and yell at the guy in the bathroom mirror to get the heck out of their apartment (okay, maybe that’s slightly hyperbolic), could we maybe have a sticky post updated periodically with the most current Linux installation instructions in one handy place?

The first thing I screwed up was that I used the software center to install it as me, instead of using going to the CLI and typing sudo dpkg -i nameofthingiwanttoinstall.deb (Yeah, I know. Dumb mistake.)

Beyond that, I remember that I need to have one of the GStreamer sets installed (I always install good, bad, and ugly anyway), and for spellcheck, the 32-bit aspell libraries, but other than that I’m drawing a blank here, guys.

Check the Scrivener Wiki, I’m not sure how up to date it is, but there is a page on getting everything running.

It wasn’t up to date, but it is now. Thanks.
As it turned out, my memory isn’t quite as pathetic as I thought it was.

Thanks for fixing the page!

No problem.
I went back later and updated a few things about WINE installation, as well, listing the exact steps I went through with the newer 1.3.11 version, so if you or someone else more knowledgeable than I could look it to over to make sure I didn’t screw anything up, I’d appreciate it.

I think we should keep it general. Not everyone is using ubuntu. Plus if you don’t know how to install WINE, you really shouldn’t be trying to use it to run Scrivener, given the tweaking via winetricks it needs. (That and if you run anything else with WINE, it has to be done in a different wineprefix, given the conflicts with some of the native libraries that need to be installed.)

Further edit: there are so many distros out there with different package managers (or no package manager at all) that we should keep the directions specific to installing Scrivener, assuming a functioning (read: current) install of WINE. Installing software is a basic skill that everyone should know how to do, if they’re using linux. (And that includes knowing how to do it via ./configure && make && make install, need be.)

Very good points. At the same time, though, there are newbies who are still getting comfortable with things and who are just getting over “penguin-phobia.” And nearly all of them are using a distro with a GUI and a package manager–although, as you said, the instructions should not be so distro-specific. Even if Ubuntu is the most popular desktop Linux distro out there, plenty of people use something else.

I left your edits in place–and thanks for doing that, by the way–and instead of putting step-by-step installation instructions for Ubuntu, linked to winehq’s instruction page that has links for for various distros, because while you’re correct that it isn’t our job to teach them how to install Wine, it can’t hurt to point them in the right direction. If they don’t need the instructions, they won’t go there. But if they do, it’s taken care of without cluttering up our wiki. Also, since the new winetricks has a GUI and is usually installed with the latest Wine (and therefore doesn’t need to be chmoded to execute), I put that information there as well while leaving your CLI instructions intact.


If I tend to over-explain on pages like that, here’s why:

Everybody was a newbie at some point. They have to start somewhere. If some newbie wants to make Scrivener running on Wine his or her first project, then hey… Why not? At least they’re trying to learn, and the instances are far too common in which, instead of teaching people what they want and need to learn, far too many of us take an RTFM attitude toward newbies, when a lot of them just need someone to walk them through the parts–often one single little step–that they didn’t quite get. It was just a couple of years ago that I took the plunge into Linux, and it was sometimes frustrating to be trying to learn things only to have more experienced users tell you that if you have to ask stupid newbie questions, you shouldn’t be using Linux.

'Cause see, when you’re a total newbie, you really don’t know how to do anything yet. And even though there are manual pages, many of them assume knowledge that a brand new user doesn’t possess. If we’re to insist that everyone should know how to do things with the CLI on their first day using Linux–including things for which we have perfectly good GUIs–well… There will be very few new Linux users. One of the things that keeps many people from trying out Linux is the perception that they’ll have to use a terminal for everything, and that day-to-day basic Linux is hard and complicated. And we reinforce this. Why bother with even having GUIs if we’re going to insist that people should know the command line from the very beginning?

While we don’t want to hand-hold them too much, I know I, for one, was more comfortable knowing that there were easily-accessible instructions I could go to, a GUI I could use, and more experienced people of whom I could ask questions when I couldn’t figure something out on my own–even though I usually didn’t need the extra help. A lot of it is a confidence thing, and they’ll get that as they go. While I’m learning to love the CLI now, I would never have gotten there if not for using GUIs first. And it didn’t help when I’d ask a question only to get a response like, “if you don’t know that, what are you doing trying to use Linux?” or “RTFM,” or, “Well just (techspeak techspeak techspeak techspeak)! How hard can it be? Pffft!” Oh, or the best yet, “Go learn something and come back when you know what you’re doing.”

Uh, yeah… That’s was I was trying to do. Learn something. But just like in school, some of us have questions that aren’t answered in the books we have at hand. Sometimes we just need someone to point us to a resource that breaks things down for us a bit more. I’d read the man pages, and Googled for answers, but there were still (and are still) things I didn’t quite “get.” And I’d have learned a lot faster had a greater number of experienced users been like, “Oh, a newbie. Yeah, you’ll love Linux once you get used to it. Here’s a good resource that explains what you’re asking about, and if you don’t understand something in it PM me.”

So yeah, this got a lot longer than I intended. My main point is that newbies are, well… newbies. And we have more newbies now than we’ve had in a long time. They have to learn somehow, and I think it’s a good thing if we try to help them learn at every opportunity.

You’re not understanding.

If I’m looking for instructions on installing software that’s using some complicated thing, I don’t want an essay. I want clear steps. And making it so ubuntu-specific will drive away others, thinking it’s not going to run on their system. (Assuming they haven’t figured it out for themselves.) Ever read the README or INSTALL files that come with source? There’s always a section on installing it with clear, numbered steps. Same goes for any application on the wine app database.

There’s a place and a time to help newbies, and it’s not in install instructions.

Cool. Sorry I misunderstood you–It just tripped a couple of triggers. And you’re right that it should be clear steps instead of long explanations, and not distro-specific. Check out what’s there now and see if you agree that it walks the line between good instruction and too much hand-holding.

I think the new version’s fine.

Maybe it’s a culture thing, but in situations like this, I’ve found that if people need more in-depth help, they generally come to the forums, where they’d (hopefully) get advice in how to do things like use winetricks or install wine. (It can be tricky, but it’s loads easier from version 1.1 on.)

The need for information versus clarity in tech writing is a very fine balance. Like you, I get annoyed when there are no build instructions for something that clearly needs them. Or even worse, when the list of dependencies isn’t given, and you’re stuck running config, seeing what blows up, installing a dependency, clearing the config cache, then running config again.

For instance, I love csound, and wrote my dissertation pieces using it, but it is a cast-iron pain in the ass to build, namely because the instructions they give are so horrible. (And a few critical steps are left out.) When you’ve fought with the source tarball all day only to read “just use your distro’s package,” and there is no package, it’s more than a bit infuriating.

Well-written build instructions are a thing of beauty. For instance, I really like the style of Alien’s wiki for slackware-related things: … elbuilding

He takes a complicated procedure that has real potential to make your system unusable and presents the information in concise steps with just enough information to learn about the process.

And yeah, I really need to work on brevity. That initial thing I wrote up there, upon looking at it again, was waaaaaaay too wordy, in addition to being too distro-specific. I tend to over-explain even at the best of times, as I’m sure my wife could tell you. Even in my fiction, I generally end up cutting about twenty percent or so between my first and final drafts. It’s especially embarrassing considering that a couple of my friends teach technical writing at KU.

BTW, that wiki you pointed me to as a technical writing example? Compiling my own kernel is something I’ve always wanted to try my hand at–Not that I need to, just because it’d be cool to know how. One of these days I’ll try it out on a virtual machine (after much more study, of course) or an old spare. If you hear on the news someday that there’s a new and unexplained crater in Kansas, it’ll probably be because I did something really stupid and my machine (or my head) exploded.

Heh, and people always say that I need to explain more. :wink: I think my brain gets going quicker than my fingers, so I wind up thinking a thing is adequately explained, but isn’t. Doesn’t help that I type around 95 wpm, too.

Compiling a kernel really isn’t difficult. It’s just got a lot of steps, and if you do something wrong, you can make your computer boot weirdly (or not at all.) I almost always forget to compile in something important (like ext3 file support). Which means the thing will boot just fine, but good luck mounting anything after that. It’s a useful thing to know how to do, especially using WINE, because newer versions of the kernel have better support for some things. For instance, there’s a fatal bug in the 2.6.35 kernel that makes World of Warcraft with WINE crash at login. (Guess what version of the kernel was shipping with Ubuntu and slackware at the time.) Or I do a lot of multimedia stuff, so I need a kernel with low latency. The kernel that ships with most distros is huge, so it doesn’t hurt to not have compiled in the things you don’t need. (Like PCMCA for a desktop.)

Best time to learn is right after you’ve done a clean install. That way there’s nothing to worry about losing, if you have to reinstall the OS. (Sometimes it’s easier to fix your mistake–like if you forget ext3 support–and sometimes it’s easier to just wipe/reinstall.) I think shooting yourself in the foot can be a good learning experience, too. (Ask me about the time I accidentally deleted bash, or the time I deleted glibc.)

I would never swap out my live kernel with a new build and then reboot and pray. I’d always configure the boot loader to use the new build as an alternate, then boot into the alternate and run that for a month. If nothing weird comes up, then I’d remove the old boot config and make the newer one the default.

LOL. Yeah, I always keep the old one around, as well.

I’ll need to read up at least a little bit to decide what I do and don’t want in my kernel, and to make sure I actually understand at least some of what’s going on and why. That’s a big part of why I want to learn to compile my own kernel in the first place–It’ll force me to learn more about the underpinnings of everything. I mean, I’m still not entirely clear on where the kernel ends and GNU begins. Pathetic, I know, but I’m getting there. Slowly but… Well, slowly.

Anyway, thanks for your patience, man. I’ve bookmarked that wiki, and I’ll be going through it. It looks like I can learn a lot there.

No prob. Like AmberV brought up, there are a few ways to do it, and it’s a good idea to not completely burn your bridges with the old kernel before making certain the new one works. I’m less careful these days because it’s one of the first things I do, and I can always reinstall over it, need be.

If you want to really learn linux, this is a great project: I used an LFS distro for awhile. It’s a good read, even if you aren’t crazy enough to roll your own. that’s a good website, too. Most of the people there know their stuff and are really helpful. There’s a huge range of experience among the posters, from compete beginners, to crusty BOFH types.

Sweet! Thanks, man!

And for now I’m going to stop procrastinating and see if I can make a writing deadline.

Heh. What do you think I’m doing? Procrastination is an art form!