Having been through Verizon, T-Mobile, and AT&T over the years (never tried Sprint), my conclusion is they're all way oversold with shitty reliability and doubly shitty and uneven customer service. Typical megacorporations to whom any individual customer matters NOT AT ALL.
I've been walking around with DRM-free files for over a year. Anyway, after stripping of them of DRM, I changed the filenames, and added prefixes to the titles (my real goal) to "categorize" them, which is why I wanted to unDRM them in the first place--adding text prefixes to the titles to indicate category makes it easier to use a Kindle without folder capability.
Wait, I've been using MobiDeDRM for a while with my Kindle's Mobi serial number to strip the DRM and leave me with Mobi files. How is this different, exactly?
Re:Speaking for myself as a Swedish brick driver,
on
A Requiem For Saab
·
· Score: 0, Troll
Toyota/Honda, I suppose. Something reliable and of reasonable quality. Certainly not American.
Um... Because Oldsmobile, Pontiac, Plymouth
on
A Requiem For Saab
·
· Score: 1
and Saturn suck? (Saturn to a lesser degree at first, but eventually it was of course ruined by Detroit.)
Speaking for myself as a Swedish brick driver,
on
A Requiem For Saab
·
· Score: 5, Insightful
I lose any interest in the brand the moment an American company buys it, because I know that the quality of the "American version" isn't going to hold a candle to the Swedish version. Once the Americans get their grubby little hands on it and start to try to integrate it into their manufacturing and supply chain and QC practices, the car's gonna just be another Chevy.
If I wanted a Chevy, I'd buy a chevy.
I'm finally getting ready to replace my '84 with 300k miles on it. When I do, I'm buying used, and I'm buying the "last Swedish year." I'm not touching any GM Saabs or Ford Volvos.
Exactly. There was a moment (between Red Hat 9 and say Fedora 2 or 3, in Red Hat land) when the best of both worlds was present... You COULD use perfectly useful GUI tools to manage things and it was great for end users to have them at that level of functionality, but you COULD also still manage your system with an xterm and vi, adding things to the.xinitrc/.xsession process, using xset to manage power saving, compiling your own kernels and assuming that in most cases it would work with the userland and installing these kernels from a root shell.
Now.xinitrc/.xsession are ignored unless you radically reconfigure things. The GNOME startup is (as you say) not only opaque but dispersed across hundreds of files not only in $HOME but also in/usr (just try to manage your menus without alacarte or change your icons in Do-Docky), the X resources system and classic arguments like -geometry are absolutely useless (you actually have to start apps one by one and hunt down configuration tools in order to affect their behavior).
On top of that, when you compile a kernel, virtually every systemic option threatens to fail to work with your userland. You have to trudge through documentation to see whether or not virtually every other option is necessary for some subsystem, and if you fail, you will not boot (or will not manage to get to your desktop). On top of that, installing a kernel now involves initrd management and questions about whether parts of the userland depend on vendor extensions to the kernel.
Yes, some of this is Red Hat, but it's also typical with ubuntu and SuSE, virtually all of the "leading" distributions.
Those who say "just switch to Slackware" or "just switch to Debian" miss the fact that full current hardware support (which these days is more and more in the userland) requires these updated userlands.
There is no essential reason why userlands these days have to ignore things like -geometry, -xrdb arguments (and the X Resource Database).xinitrc/.xsession, etc.
It's a philosophical shift toward a monolithic SYSTEM (like Windows) and away from Unix modularity. People used to complain about the monolithic KERNEL. Now dispersed parts of the installation across all of userland are critical. There is virtually no modularity left in the most recent distros.
It's a shame, because I think the parallel mode of thinking (we'll honor old UNIX standards *and* build new user-friendly tools around them) was a much better way to go.
No. There are many things that you might want a system to do without a GUI. There are many instances (embedded development, or quasi-embedded systems/headless role-oriented systems) where you don't want to even install the GUI, much less a web browser.
This is the Linux development that troubles me... the perception that the important thing for Linux to do is become a great browsing and multimedia platform, and the right way to do this is throw everything that's not directly supportive of this singular form of use away--simply discard it. In the midst of all of that, the incredible flexibility of the UNIX paradigm for a variety of computing and data processing tasks is being lost.
Excuse me? I know how init used to work, how it's supposed to work still IMHO. I think you'll find that between Plymouth and udev, there's much in the boot and hardware initialization process of Fedora that has nothing to do with init scripts.
Laziness? Books? I wrote six books on Red Hat Linux offerings between 1997 and 2004 for Pearson. More often than not as we were writing chapters on this stuff, I was conferencing with the editorial team and Red Hat's maintainers. Why? Because there was no existing documentation of how things worked or how to accomplish various tasks, and in technical review they were pointing out gaps in the coverage of what we (myself and the editorial team) had figured out from dissecting scripts and code.
In the UNIX I grew up with, you could have written a book straight from the manpages.
the terms surrounding this software in a way that belies many of the benefits routinely claimed by open source advocates.
Of what do "access to," "freedom to," and "re-use" consist? Does not the "millions of eyes" trope imply an actual base of users and developers that are conversant with the code? Does it not require information? Do you honestly mean to argue that the "millions of eyes" in question are beginning with "Line 1" of the Linux kernel and reading through it line-by-line, then proceeding to glibc, then to Xorg, before installing, so that they are prepared to participate?
I can tell you as a developer AND technical writer that when I make a bug report, I have rarely read the code for the project in question... and the extent to which I provide details in the bug report is directly proportional to the amount of documentation available to me to help me to determine the basic architectural layout of the project. More documentation about how it works and how it is supposed to work = more detail (and usefulness) in the bug report. Less documentation and it can just come down to "It crashed. Fedora 12, RPM version X."
Openness does not exist in a vacuum; its benefits do not proceed from the legal construct in question. The benefits of openness proceed precisely in the end from the social availability to users of knowledge about the software they are using. This is the starting point for patches, supporting or following projects, bug reports, and all of the other things in the open source "economy."
It absolutely does not begin with every would-be open source community participant reading all of the source in question, from square one, without any idea of how the larger architecture of the system fits together, which body of source to read first, how the system is meant to work (big picture), and so on. It's simply disingenuous to argue this.
What is the benefit of open source if the openness doesn't actually pragmatically exist? Openness implies access, understanding, knowledge, transparency. Without documentation, none of these exist. Yes, you can get ahold of the source package shipped by your distro, extract it into files, and study the source code as documentation.
You can also run all of Windows 7 through a disassembler and you can make changes to your own system with a hex editor editing DLL libraries by hand. That's nearly the same kind of "documentation" and "openness" as far as most users are concerned, yet nobody would seriously make the argument that this brings any kind of "openness" to Windows 7.
right now, "Use the source!" and "Documentation is bad!"
Use the source: "I do not develop this software for income, I do it for free out of the kindness of my heart because I find it interesting. I do not find writing documentation to be interesting, so I won't do it. You are free to read the source and do it. The strength of open source is that you have the source. Therefore, if you want documentation, the source is where to start, because I'm certainly not going to write any." >> This is a fair point, but these projects, totally lacking in documentation, should not then be included by distributors in base installations or as critical system components. It is simply bad to incorporate documentation-free components into the core system. If nothing else, distro maintainers ought to find someone to write docs before including these components.
Documentation is bad: "Users do not want to read documentation, and therefore won't. Since we can assume that they won't, the system should 'Just Work[TM]' for you without it. If it fails to do this, the system is at fault and you should file a bug report and/or contribute if you're able, but the need for documentation is evidence of bad software design." >> This attitude, increasingly all-too prevalent, is the one that I really can't stand. Really. The essential argument here is that software should never be flexible because users are all identical. That, to my eye, is a losing proposition long-term and I'll never think it's a useful perspective.
Nothing is more frustrating than the knowledge that something would be two minutes simple if only you could find documentation on it SOMEWHERE, but you are forced eventually to download an SRPM and grumble through someone's source and launch scripts to locate the one simple argument that you needed, wasting an hour on what should have been a 30-second manpage problem--only the manpage doesn't exist.
man pages used to be great. They used to absolutely rule and tell you exactly how to use any part of the system. Now, most things are lacking a man page entirely (man openoffice, man gnome, man kde, man evolution) and the man pages that do exist either tell you nothing or tell you nothing useful.
And, even more ironically, there used to be dozens of desktop manpage viewers, most notably xman from the basic X applications toolset installed on all UNIX and Linux desktops with X. You could even type "man:command" into most Linux browsers and read the manpage. Now none of this exists; it has been TAKEN OUT under the theory that user access to documentation or utilities of this kind is bad for some reason.
I've been a Linux user since 1993 and the state of Linux documentation today is worse than ever before if you don't happen to be an actual coder on a specific project reading project documentation for it in order to facilitate your work and contributions.
Back in the day, there were manpages, info pages, comprehensive documentation at/usr/doc or/usr/share doc for specific packages, and documentation files in nearly every source directory that you compiled yourself. You could also pick up just about any book on UNIX (System V Bible for SysV-like distros, or various BSD books) and apply much of what was said to Linux as well.
Everything was well-understood and common to the general state of things in the UNIX world and if you didn't understand something, a quick apropos/man or info or visit to/usr/doc or/usr/share/doc would result in enlightenment.
I'm a Red Hat/Fedora user since Red Hat 4 (Slackware before that) and as a 25-year UNIX veteran, I often feel like I have no idea what's going on in (for example) the init process, X configuration, desktop management, app resources/configuration, etc. Where are the dotfiles located? Where are the/etc components? What are the command-line arguments? Where are the manual pages? What documentation does exist is generally in the awful "Help Tool" format (click Help -> Help Contents in an application window and get a lot of prose for beginners). This documentation typically offers NO INFORMATION beyond the navigation of the user interface for the application. Nothing on system resources, locations of configuration files, dependencies, APIs, command line arguments, or anything that would allow you to either troubleshoot or modularly re-use the software item in question.
The system-level stuff (PackageKit, PolicyKit, SELinux, Udev, HAL, Plymouth etc. etc.) does not offer any clear location for configuration and typing for example "man selinux" brings up a couple of paragraphs with no detail. It refers to a pile of other manual pages, none of them installed by default. There is no overview. And SELinux is probably the most transparent of all of these.
The desktop is completely unmanageable if something breaks; the dotfiles are not in any concise location. gconf-editor is not installed by default and even after you do install it, there's no documentation on the options that it contains. It's not clear how to cause a command to execute on startup. You can go to GNOME startup options in a menu through which you have to use a GUI program to "add" things to the startup process, but the environment that's being configured for the processes spawned this way is not documented and many attempts to execute commands using this method fail.
More and more it seems as though I am constantly using find and grep either in all dotfiles in a directory or as root through the entire/etc,/usr/share, and/usr/lib directories to identify through keywords or binary strings either binaries or text files relevant to tasks I want to accomplish, then paging through them or opening the binaries up in a hex editor to try to grok what I need to change through sheer intuition.
Yes, I suspect there is documentation "out there" somewhere, but spending an hour trying to Google where it is located in each instance is an hour that I already don't have and that now can't go toward actually reading and grokking the documentation in question. But it appears to be just too much to provide easy directions to the technical documentation that exists, if it exists, in each case.
There is a definite ethos of "try to hide the system from the user" that has emerged in Linux and it does not make me happy, as is obvious here. I now spend several days each Fedora upgrade trying to bang my personal system into the shape I want it to be in. It used to be really simple to upgrade, and it was one of the greatest things about Linux. Just tr
First worry: Physical item security (your wallet, your mobile phone, your netbook, your backpack) Second worry: Self security (getting kidnapped for ransom/assaulted/mugged after being seen with all of above)
They are not gonna sit around trying to crack your SSL connection. They are gonna notice your netbook and mobile phone and the fact that you are staying at a hotel that offers WiFi to its guests and they are gonna come steal all your stuff or worse, you.
Stop thinking like a geek and start thinking like a traveler.
because of the DRM. As a longtime fan of the Myst series of games (one of the type that played every one of them from beginning to end without spoilers) I ran out and got RealMyst the moment it came out. The interface was fantastic; it was twice as immersive as the original and just as transparent. But it took me a while to get there.
As your typical technojunk collector, I had about three optical drives connected to my main PC at the time and about another four or five or varying speeds and burning technologies laying around collecting dust. NONE of them worked with the RealMYST DRM (skips and blips or wouldn't run at all).
I finally had to go to Computer Gaming World or some such site and download a noCD crack to make it work, but only after I'd wasted a day popping my case and trying it out with every friggin' optical drive. That started the practice (almost forgotten now, I never play games any longer) of just getting the crack immediately for any game I bought, without even bothering to try to play the game uncracked, which lasted several years.
with Fedora, multiple versions, multiple different machines and sound hardware families. Sometimes I thought it was working, but then I would find some critical aspect of sound that didn't work or an upgrade would break it a day or two later and sound would disappear. Even those moments when it was partially working, sound was always out of sync and choppy and consumed heavy CPU resources.
I always de-install the damned thing, and then suddenly sound works perfectly. It's like an extra component that's insanely complex and designed especially to BREAK sound in Linux.
Infuriating story: I dated someone in my Ph.D. program who came here on a Fulbright fellowship funded by the state department. They invested a LOT of money and she was very, very good. But because Fulbright brings people in on a J-1 visa, there was the requirement that she had to leave afterward. Not eligible to say no matter what, not even if she married an American.
This got to be such an issue in her personal life (knowing that she had to leave, that the moment she was done with her Ph.D. program here, she'd have to uproot and leave everything behind and start all over again) that she basically decided it wasn't worth it to finish the Ph.D. in this country, better to get a head start on the life that came next. So after investing huge amounts of money in multiple years of her work here, the U.S. government effectively pushed her right out.
So not only will the U.S. institution not get the prestige from having its name attached to her work, the U.S. won't get the fruits of her labor, despite the fact that she desperately wanted to build a life here and was funded to come and study by our tax dollars.
Resolution is good Parts are cheap Toner is cheap Expansion components are cheap Speed is reasonable Longevity is great Language (PCL) is widely supported
When my Brother laser died and proved to be essentially unserviceable (just try to cleanly replace the fuser on one of the older models), I decided I was going back to HP no matter what. I got a LaserJet 2100, a stackable 3rd tray (additional 500 sheet capacity), a JetDirect card and a wireless access point, and three spare toner cartridges for it, all on eBay for a total of about $150.
I've been using it now for about three years and have run about 50,000 sheets through it with no problems. It's never needed to be reset, I've never had driver issues, and it seems content to just sit on the wireless network and slave away. If something does go wrong, there's the added benefit that parts are readily available and it's reasonably easy to work on in comparison to those very cheap consumer printers from many brands today.
Slashdot Mirror
Having been through Verizon, T-Mobile, and AT&T over the years (never tried Sprint), my conclusion is they're all way oversold with shitty reliability and doubly shitty and uneven customer service. Typical megacorporations to whom any individual customer matters NOT AT ALL.
I've been walking around with DRM-free files for over a year. Anyway, after stripping of them of DRM, I changed the filenames, and added prefixes to the titles (my real goal) to "categorize" them, which is why I wanted to unDRM them in the first place--adding text prefixes to the titles to indicate category makes it easier to use a Kindle without folder capability.
Wait, I've been using MobiDeDRM for a while with my Kindle's Mobi serial number to strip the DRM and leave me with Mobi files. How is this different, exactly?
Toyota/Honda, I suppose. Something reliable and of reasonable quality. Certainly not American.
and Saturn suck? (Saturn to a lesser degree at first, but eventually it was of course ruined by Detroit.)
I lose any interest in the brand the moment an American company buys it, because I know that the quality of the "American version" isn't going to hold a candle to the Swedish version. Once the Americans get their grubby little hands on it and start to try to integrate it into their manufacturing and supply chain and QC practices, the car's gonna just be another Chevy.
If I wanted a Chevy, I'd buy a chevy.
I'm finally getting ready to replace my '84 with 300k miles on it. When I do, I'm buying used, and I'm buying the "last Swedish year." I'm not touching any GM Saabs or Ford Volvos.
silly.
Exactly. There was a moment (between Red Hat 9 and say Fedora 2 or 3, in Red Hat land) when the best of both worlds was present... You COULD use perfectly useful GUI tools to manage things and it was great for end users to have them at that level of functionality, but you COULD also still manage your system with an xterm and vi, adding things to the .xinitrc/.xsession process, using xset to manage power saving, compiling your own kernels and assuming that in most cases it would work with the userland and installing these kernels from a root shell.
Now .xinitrc/.xsession are ignored unless you radically reconfigure things. The GNOME startup is (as you say) not only opaque but dispersed across hundreds of files not only in $HOME but also in /usr (just try to manage your menus without alacarte or change your icons in Do-Docky), the X resources system and classic arguments like -geometry are absolutely useless (you actually have to start apps one by one and hunt down configuration tools in order to affect their behavior).
On top of that, when you compile a kernel, virtually every systemic option threatens to fail to work with your userland. You have to trudge through documentation to see whether or not virtually every other option is necessary for some subsystem, and if you fail, you will not boot (or will not manage to get to your desktop). On top of that, installing a kernel now involves initrd management and questions about whether parts of the userland depend on vendor extensions to the kernel.
Yes, some of this is Red Hat, but it's also typical with ubuntu and SuSE, virtually all of the "leading" distributions.
Those who say "just switch to Slackware" or "just switch to Debian" miss the fact that full current hardware support (which these days is more and more in the userland) requires these updated userlands.
There is no essential reason why userlands these days have to ignore things like -geometry, -xrdb arguments (and the X Resource Database) .xinitrc/.xsession, etc.
It's a philosophical shift toward a monolithic SYSTEM (like Windows) and away from Unix modularity. People used to complain about the monolithic KERNEL. Now dispersed parts of the installation across all of userland are critical. There is virtually no modularity left in the most recent distros.
It's a shame, because I think the parallel mode of thinking (we'll honor old UNIX standards *and* build new user-friendly tools around them) was a much better way to go.
I wholeheartedly agree!
No. There are many things that you might want a system to do without a GUI. There are many instances (embedded development, or quasi-embedded systems/headless role-oriented systems) where you don't want to even install the GUI, much less a web browser.
This is the Linux development that troubles me... the perception that the important thing for Linux to do is become a great browsing and multimedia platform, and the right way to do this is throw everything that's not directly supportive of this singular form of use away--simply discard it. In the midst of all of that, the incredible flexibility of the UNIX paradigm for a variety of computing and data processing tasks is being lost.
Excuse me? I know how init used to work, how it's supposed to work still IMHO. I think you'll find that between Plymouth and udev, there's much in the boot and hardware initialization process of Fedora that has nothing to do with init scripts.
Laziness? Books? I wrote six books on Red Hat Linux offerings between 1997 and 2004 for Pearson. More often than not as we were writing chapters on this stuff, I was conferencing with the editorial team and Red Hat's maintainers. Why? Because there was no existing documentation of how things worked or how to accomplish various tasks, and in technical review they were pointing out gaps in the coverage of what we (myself and the editorial team) had figured out from dissecting scripts and code.
In the UNIX I grew up with, you could have written a book straight from the manpages.
the terms surrounding this software in a way that belies many of the benefits routinely claimed by open source advocates.
Of what do "access to," "freedom to," and "re-use" consist? Does not the "millions of eyes" trope imply an actual base of users and developers that are conversant with the code? Does it not require information? Do you honestly mean to argue that the "millions of eyes" in question are beginning with "Line 1" of the Linux kernel and reading through it line-by-line, then proceeding to glibc, then to Xorg, before installing, so that they are prepared to participate?
I can tell you as a developer AND technical writer that when I make a bug report, I have rarely read the code for the project in question... and the extent to which I provide details in the bug report is directly proportional to the amount of documentation available to me to help me to determine the basic architectural layout of the project. More documentation about how it works and how it is supposed to work = more detail (and usefulness) in the bug report. Less documentation and it can just come down to "It crashed. Fedora 12, RPM version X."
Openness does not exist in a vacuum; its benefits do not proceed from the legal construct in question. The benefits of openness proceed precisely in the end from the social availability to users of knowledge about the software they are using. This is the starting point for patches, supporting or following projects, bug reports, and all of the other things in the open source "economy."
It absolutely does not begin with every would-be open source community participant reading all of the source in question, from square one, without any idea of how the larger architecture of the system fits together, which body of source to read first, how the system is meant to work (big picture), and so on. It's simply disingenuous to argue this.
You've actually hit on one of the few examples that "sort of" works still in Linux (though it could be better).
On Fedora 12:
$ apropos burn
brasero (1) - Simple and easy to use CD/DVD burning application for the Gnome Desktop
$ man brasero
If only it actually worked this way (as it used to) for most of the rest of the Linux applications/tasks ecosystem.
What is the benefit of open source if the openness doesn't actually pragmatically exist? Openness implies access, understanding, knowledge, transparency. Without documentation, none of these exist. Yes, you can get ahold of the source package shipped by your distro, extract it into files, and study the source code as documentation.
You can also run all of Windows 7 through a disassembler and you can make changes to your own system with a hex editor editing DLL libraries by hand. That's nearly the same kind of "documentation" and "openness" as far as most users are concerned, yet nobody would seriously make the argument that this brings any kind of "openness" to Windows 7.
right now, "Use the source!" and "Documentation is bad!"
Use the source: "I do not develop this software for income, I do it for free out of the kindness of my heart because I find it interesting. I do not find writing documentation to be interesting, so I won't do it. You are free to read the source and do it. The strength of open source is that you have the source. Therefore, if you want documentation, the source is where to start, because I'm certainly not going to write any." >> This is a fair point, but these projects, totally lacking in documentation, should not then be included by distributors in base installations or as critical system components. It is simply bad to incorporate documentation-free components into the core system. If nothing else, distro maintainers ought to find someone to write docs before including these components.
Documentation is bad: "Users do not want to read documentation, and therefore won't. Since we can assume that they won't, the system should 'Just Work[TM]' for you without it. If it fails to do this, the system is at fault and you should file a bug report and/or contribute if you're able, but the need for documentation is evidence of bad software design." >> This attitude, increasingly all-too prevalent, is the one that I really can't stand. Really. The essential argument here is that software should never be flexible because users are all identical. That, to my eye, is a losing proposition long-term and I'll never think it's a useful perspective.
Nothing is more frustrating than the knowledge that something would be two minutes simple if only you could find documentation on it SOMEWHERE, but you are forced eventually to download an SRPM and grumble through someone's source and launch scripts to locate the one simple argument that you needed, wasting an hour on what should have been a 30-second manpage problem--only the manpage doesn't exist.
man pages used to be great. They used to absolutely rule and tell you exactly how to use any part of the system. Now, most things are lacking a man page entirely (man openoffice, man gnome, man kde, man evolution) and the man pages that do exist either tell you nothing or tell you nothing useful.
And, even more ironically, there used to be dozens of desktop manpage viewers, most notably xman from the basic X applications toolset installed on all UNIX and Linux desktops with X. You could even type "man:command" into most Linux browsers and read the manpage. Now none of this exists; it has been TAKEN OUT under the theory that user access to documentation or utilities of this kind is bad for some reason.
I've been a Linux user since 1993 and the state of Linux documentation today is worse than ever before if you don't happen to be an actual coder on a specific project reading project documentation for it in order to facilitate your work and contributions.
Back in the day, there were manpages, info pages, comprehensive documentation at /usr/doc or /usr/share doc for specific packages, and documentation files in nearly every source directory that you compiled yourself. You could also pick up just about any book on UNIX (System V Bible for SysV-like distros, or various BSD books) and apply much of what was said to Linux as well.
Everything was well-understood and common to the general state of things in the UNIX world and if you didn't understand something, a quick apropos/man or info or visit to /usr/doc or /usr/share/doc would result in enlightenment.
I'm a Red Hat/Fedora user since Red Hat 4 (Slackware before that) and as a 25-year UNIX veteran, I often feel like I have no idea what's going on in (for example) the init process, X configuration, desktop management, app resources/configuration, etc. Where are the dotfiles located? Where are the /etc components? What are the command-line arguments? Where are the manual pages? What documentation does exist is generally in the awful "Help Tool" format (click Help -> Help Contents in an application window and get a lot of prose for beginners). This documentation typically offers NO INFORMATION beyond the navigation of the user interface for the application. Nothing on system resources, locations of configuration files, dependencies, APIs, command line arguments, or anything that would allow you to either troubleshoot or modularly re-use the software item in question.
The system-level stuff (PackageKit, PolicyKit, SELinux, Udev, HAL, Plymouth etc. etc.) does not offer any clear location for configuration and typing for example "man selinux" brings up a couple of paragraphs with no detail. It refers to a pile of other manual pages, none of them installed by default. There is no overview. And SELinux is probably the most transparent of all of these.
The desktop is completely unmanageable if something breaks; the dotfiles are not in any concise location. gconf-editor is not installed by default and even after you do install it, there's no documentation on the options that it contains. It's not clear how to cause a command to execute on startup. You can go to GNOME startup options in a menu through which you have to use a GUI program to "add" things to the startup process, but the environment that's being configured for the processes spawned this way is not documented and many attempts to execute commands using this method fail.
More and more it seems as though I am constantly using find and grep either in all dotfiles in a directory or as root through the entire /etc, /usr/share, and /usr/lib directories to identify through keywords or binary strings either binaries or text files relevant to tasks I want to accomplish, then paging through them or opening the binaries up in a hex editor to try to grok what I need to change through sheer intuition.
Yes, I suspect there is documentation "out there" somewhere, but spending an hour trying to Google where it is located in each instance is an hour that I already don't have and that now can't go toward actually reading and grokking the documentation in question. But it appears to be just too much to provide easy directions to the technical documentation that exists, if it exists, in each case.
There is a definite ethos of "try to hide the system from the user" that has emerged in Linux and it does not make me happy, as is obvious here. I now spend several days each Fedora upgrade trying to bang my personal system into the shape I want it to be in. It used to be really simple to upgrade, and it was one of the greatest things about Linux. Just tr
Data theft should be your last worry.
First worry: Physical item security (your wallet, your mobile phone, your netbook, your backpack)
Second worry: Self security (getting kidnapped for ransom/assaulted/mugged after being seen with all of above)
They are not gonna sit around trying to crack your SSL connection. They are gonna notice your netbook and mobile phone and the fact that you are staying at a hotel that offers WiFi to its guests and they are gonna come steal all your stuff or worse, you.
Stop thinking like a geek and start thinking like a traveler.
will be paved with companies that don't think doing business in China is important.
who is currently at 11 and will probably upgrade, I have installed Fedora cleanly on:
- Parents white-box PC
- Wife's Toshiba Satellite
- Personal laptops (Thinkpad T21->Thinkpad T23->Toshiba Portege m200->Thinkpad T60)
- Best friend's white-box PC
- Quad-processor Compaq Proliant Xeon server
- Acer netbook
All in the last few years. I've used Fedora Core 1, Fedora 3, Fedora 4, Fedora 7, Fedora 8, Fedora 9, Fedora 10, and Fedora 11.
Never had any trouble; insert CD, install, go.
because of the DRM. As a longtime fan of the Myst series of games (one of the type that played every one of them from beginning to end without spoilers) I ran out and got RealMyst the moment it came out. The interface was fantastic; it was twice as immersive as the original and just as transparent. But it took me a while to get there.
As your typical technojunk collector, I had about three optical drives connected to my main PC at the time and about another four or five or varying speeds and burning technologies laying around collecting dust. NONE of them worked with the RealMYST DRM (skips and blips or wouldn't run at all).
I finally had to go to Computer Gaming World or some such site and download a noCD crack to make it work, but only after I'd wasted a day popping my case and trying it out with every friggin' optical drive. That started the practice (almost forgotten now, I never play games any longer) of just getting the crack immediately for any game I bought, without even bothering to try to play the game uncracked, which lasted several years.
with Fedora, multiple versions, multiple different machines and sound hardware families. Sometimes I thought it was working, but then I would find some critical aspect of sound that didn't work or an upgrade would break it a day or two later and sound would disappear. Even those moments when it was partially working, sound was always out of sync and choppy and consumed heavy CPU resources.
I always de-install the damned thing, and then suddenly sound works perfectly. It's like an extra component that's insanely complex and designed especially to BREAK sound in Linux.
Infuriating story: I dated someone in my Ph.D. program who came here on a Fulbright fellowship funded by the state department. They invested a LOT of money and she was very, very good. But because Fulbright brings people in on a J-1 visa, there was the requirement that she had to leave afterward. Not eligible to say no matter what, not even if she married an American.
This got to be such an issue in her personal life (knowing that she had to leave, that the moment she was done with her Ph.D. program here, she'd have to uproot and leave everything behind and start all over again) that she basically decided it wasn't worth it to finish the Ph.D. in this country, better to get a head start on the life that came next. So after investing huge amounts of money in multiple years of her work here, the U.S. government effectively pushed her right out.
So not only will the U.S. institution not get the prestige from having its name attached to her work, the U.S. won't get the fruits of her labor, despite the fact that she desperately wanted to build a life here and was funded to come and study by our tax dollars.
It boggles the mind.
Resolution is good
Parts are cheap
Toner is cheap
Expansion components are cheap
Speed is reasonable
Longevity is great
Language (PCL) is widely supported
When my Brother laser died and proved to be essentially unserviceable (just try to cleanly replace the fuser on one of the older models), I decided I was going back to HP no matter what. I got a LaserJet 2100, a stackable 3rd tray (additional 500 sheet capacity), a JetDirect card and a wireless access point, and three spare toner cartridges for it, all on eBay for a total of about $150.
I've been using it now for about three years and have run about 50,000 sheets through it with no problems. It's never needed to be reset, I've never had driver issues, and it seems content to just sit on the wireless network and slave away. If something does go wrong, there's the added benefit that parts are readily available and it's reasonably easy to work on in comparison to those very cheap consumer printers from many brands today.