the revolutionary DiscT@2TM Laser Labeling System,
...pronounced as Disc Tattoo Laser Labeling System.
[Google doesn't show a German word for tattoo.] A tattoo is a permanent marking by stippling ink designs into living skin. Or in this case, a permanent marking by stippling burn designs into compact disc designs.
I mean, renaming a file to a new directory by pointing your finger is fine if you just want to rename one file. But to suggest that this is an improvement over the command line if you've got thousands of files to shuffle around is completely ignoring the computer's ability to do mind-numbing repetitive jobs quickly and accurately.
Finger gesturing interfaces are not meant for tasks like renaming files. You're right. If someone were to try to implement that, it would be laughable. But personally, if we start using finger pointing gestures to control computers, I would hope that the mere notion of filenames are irrelevant if not antiquated. Spatial gestures for spatial problems, text descriptions for text problems.
Now, use a command-line interface to sort a thousand stock photographs according to whether they're appropriate for your latest advertising campaign, or to determine if a polyketone molecule could theoretically wiggle through a hole in a proposed crystalline lattice. Massively complicated code or a few seconds of human mindpower? I've got your finger gesture right here.
I went MicroPro.com earlier this year because they had low prices and most of the parts I wanted.
This is how they treated my order. Two computers, pretty much ripped apart into pieces because they didn't even bother TRYING to pack the parts properly. The photos show how laughable their efforts were. Laughable if it's not your order, that is.
While they did eventually replace all the parts, they (1) were hoping to get away with calling it UPS's fault, and (2) took a month to "find" the RMA parts so they could replace it.
It was only the day I threatened a BBB letter that the final RMA'd units were mysteriously "found" and replaced promptly.
The reason that it's hard to infect a Linux (/Unix/anything with a decient permission structure) system is that hardly anyone runs daily activities as root and only updates their/bin,/usr/bin, etc binaries from a known source or from source code.
While that may seem logical and common-sense to you, this is NOT obvious and intuitive to a huge newcomer/dilettante population out there.
A typical conversation on IRC:
- root (root!root@dialup123.induhvidual.qq) has joined #linux
[root] ne1 4 a question???
[Speare] Hey, root, it's a security risk to
run IRC or any software as the root
user. Set up a normal account and
use the root account just for system
administration tasks.
[root] i been on linux since 5.2, dont lecture
[root] ne1 no why/bin/ls crashes???
Seems like the de-facto third thing that every newbie wants to do, right after their first Linux distro install, is to rebuild their kernel. Why? I have no idea.
Yet almost nobody tells them how to build the kernel as non-root, or put the source anywhere but in root-writable/usr/src/linux, or why they should just stick to the pre-built, pre-audited kernels from their distro provider.
If SOMEONE wanted to zombie a lot of clueless folks, they should just distribute "helpful" kernel-building scripts.
Linux isn't secure until users know what security is.
The very idea of "forcibly placing" ones work into the "public domain by law" is quite distasteful.
Um, that's exactly what a patent is, and does. You document your method in detail for all to see, and in exchange, you can decide who uses the method for a limited amount of time. After the patent expires, potentially everyone benefits from your documentation freely.
As a semi-pro graphics artist, I really hate proprietary stock image formats. I can understand their desire to curb rampant copying, but I also dislike the lack of interoperability.
One example is the SNX format used by the Second Nature company for their screen saver images. I've purchased the discs, I would like to use them on Linux, not the native Windows.
A worse example is the Hemera HPI format used for their stock "photo objects." These are 8 CD sets of about 50,000 images in a proprietary 24bpp + alpha channel format. Something which TIFF or PNG formats handle very well. Every time I want to use an image, I have to load up Windows, use their proprietary image search and export tool.
It's my estimation that in the long run, inconvenience added through proprietary "protections" will cost these royalty-free image companies far more sales than the illicit warez-ing of their content. And what happens when those stock companies are not around to support their proprietary converters? One Windows update and users are cut off from the image libraries which should be simple to access.
GMR (giant magnetoresistance) harddisk technology will not achieve terrabit-per-square-inch densities. Experiments with EMR (extra-ordinary magnetoresistive), which exceeds 100Gb/in^2 have been successful in the lab.
After that, comes IMR (improbable magnetoresistive) where the Library of Congress fits in a square inch.
Finally, new advancements in subatomic physics leads to LMR (ludicrous magnetoresistive), giving more bits of storage than there are atoms on the platter. The "flavor" and "color" of each quark are directly manipulated and sampled by the drive head.
Of course, I'm sure the RIAA will get them shut down ASAP to prove they own the right to every aspect of our culture, including our own commentary upon that culture.
Only if those online dictionaries happen to be member organizations under the RIAA umbrella. As far as I know, they are not. The RIAA doesn't sue when someone steals a car, the RIAA doesn't sue when someone steals a loaf of bread, the RIAA doesn't sue when someone steals a copy of Microsoft Excel.
Will the dictionary companies sue? Only if they think this causes them damage. That could be a matter of corporate image [claiming the voice is a recognizable de facto trademark of a specific dictionary property], a matter of competitive advantage [claiming the compilation of words constitutes an alternative product employing their own patent-protected methods], or a matter of creative control [claiming the specific aggregation of pronunciations or the specific voice actor's performance is an artistic expression that others have no inherent right to copy]. I think each of these claims are weak in this case.
Also: Cartoon Guide to [REAL] Physics...
on
Comic Book Physics
·
· Score: 2
We have three cases here.
A study of real physics as if cartoon heros were real (such as 'how many calories would the Flash emit'),
A study of stage physics used in comedy cartoons (such as 'nothing falls slower than an anvil'),
A study of real physics using a cartoon medium to explain them.
There is an excellent book by Larry Gonick and Art Huffman to cover this last area. http://www.amazon.com/exec/obidos/ASIN/0062731009 It goes from understanding simple Newtonian and extended body stuff, magnetism and flux, electrical current, to quantum electro dynamics.
It is from this book that I finally grokked *why* a gyroscope will precess or rotate its axis when the axis is not aligned against gravity.
My apartment complex management requires the use of stove bombs. They are magnetically mounted to the overhead stove hood, and are about the same size as a can of sterno. An out-of-control stove fire would crack the can's fragile bottom, dumping a load of fire-retarding powder all over the top of the stove.
The recording industry hopes to standardize the entire computing industry on crippled hardware, nonstandard formatting for media, and to have taxpayer-funded anti-piracy enforcement squad. When the economy dips, the recording industry screams about the few percentage points of lost revenue through piracy.
The software industry, by comparison, have established open modular interfaces for stock hardware, has eliminated nonstandard formatting for media, and has a self-funded anti-piracy enforcement squad. Whether accurate or not, industry figures suggest that about a third of all software in use is pirated.
The recording industry is screaming about the impending doom for their business. I think that their approach is demonstrably bad for their business.
Microsoft (as an industry flagship) has enough liquid assets to buy all the gold in Fort Knox four times over. This isn't counting the intellectual property nor tangible property. I think that approach worked well for them.
Make the prices reasonable, even if the product is crappy, and the masses will flock to the cash registers.
The article lists these issues as why Free Software UI sucks.
Not enough software designers to get the work done.
Too many cooks spoil the code's architecture.
Free software doesn't innovate, just copies.
Volunteers only want to do cool stuff.
Volunteers don't do boring details.
Maintainers cave in and add misguided features or code rather than endure flamewars.
People want their own features to point at.
Workarounds are introduced during the devel process and never removed.
Hello? Where is the #1 reason?
FREE SOFTWARE DESIGNERS DON'T UNDERSTAND THEIR USERS' GOALS.
Sure, developers write things for themselves. Developers write things for their co-workers. But do developers of Free Software really go out and research the goals of their users?
In looking at Linux user interfaces, I see that most tools merely tie some toolkit strings onto the underlying code so that it can be manipulated. The current thinking seems to be that if the underlying driver can do something, expose that ability directly on the command line or in a preferences dialog box.
A great case-in-point is cd-burning software. Type (cdrecord --help). The typical GUI wrapper is just the Gtk equivalent of (cdrecord --help). A massive soup of options with little help for people who don't know what a leadin is, don't care what a TOC is, don't understand how the lovers Romeo and Joliet got into CD-burning, and don't understand whether they want to fixate the disc or not.
Instead, turn it over.
Who are the intended users?
What are their goals?
How would they like to get their tasks done?
Make some archetypical example users of your application. Nate the newbie. Seth the secretary. Judy the junior admin. Devin the developer. Whoever it is that needs your help to accomplish their goals, get to know these people.
A useful CD burning tool doesn't need to expose everything the driver can do. Add music files here. Add data files or folders here. Might you want to add more files at a later date? Burn the disc.
In Alan Cooper's words, "don't make the user feel stupid."
A user interface needs to start with the user, and proceed to the interface.
Wait, wait, we meant "green is the new beige!"
on
Black Is The New Beige
·
· Score: 4, Funny
PC Fashionistas exclaim, "Black is the new Beige!"
I sure hope we're not going to read an article two weeks from now which explains some computing error, and how the new fashionable color is actually something one could describe as a dusty mint color.
And please don't let them correct themselves again claiming that it's chic to use a sort of salmon/melon/peach color. I couldn't stand to boot up a computer of which the casing reminded me of tuna sashimi.
Debian does distinguish between dependency management and package management.
Aye, I understand the dpkg tool. But who uses it directly? Not too many users, and not very often. Debian doesn't focus on the distinction, and leads people to a standard front-end: apt-get.
While I like the promise of RPM, its various front-ends like up2date and redcarpet are either limited to a small source-base or are unstable due to their lax standards-checking. The RPM tools will improve, and.deb and.rpm already learn the best practices from each other over time. I stick to RPM because I stick to Red Hat.
I use Red Hat. I love the up2date tool, especially the push-down email notifications, and prefer Red Hat built packages. However, up2date and its ilk need to develop strong linting tools and 'tainted' flags for those packages that haven't been independently validated, much like the.deb process is.
Why Red Hat instead of Debian then? Personal preference, based on the personalities in the community, the corporate backing, and the currentness of the development efforts.
The leadin says that Gentoo eliminates all that RPM dependency hell. I agree, that's how most newcomers to the RPM scheme see it. A lack of higher tools and a lack of understanding has left many a new RPM user crying in frustration.
I haven't used Gentoo yet, and it may be the greatest thing since sliced bread. In the interests of helping newcomers who try RPM-based distros, however, a couple of points...
RPM is a package format, and rpm is the low-level tool that deals with those files. If you use rpm directly, you'll have to deal with the deluge of interconnecting dependencies yourself. However, it was not designed to be the sole front-line tool, it's the workhorse.
Unlike the Debian strains which all adopted the apt-get tool, each RPM-based distro has gone their own way with dependency management. Debian doesn't seem to focus so much on a distinction between dependency management and package management.
This dependency management is typically the commercialized aspect of the commercialized distro market: pay a value-added subscription fee for the ease of using a simplified network based package update/installer as a service, as well as some preferential bandwidth considerations. Faster downloads, push-down email notices, scheduled automatic installations, and other value-added services are attractive to corporate and casual users.
Service tools like up2date, redcarpet, and the like are the intended front-ends that use the rpm mechanisms to seek, download, validate, and install packages.
Much of the problem with package systems, rpm or deb, lies in the unorganized and untested packages produced haphazardly by small project folks, and the ad-hoc installations by casual users. The end users try rpm directly, or the weak gui equivalents, and at the first sign of dependency problems, they start using --nodeps or --force. Paraphrasing Asimov, "--force is the last refuge of the incompetent." The surest way to bollox an RPM machine is to --force a few packages or remove them with --nodeps, leaving a patchwork of unsatisfied dependencies. The surest way for a package maintainer to encourage such destruction is to blindly make packages that depend on too much, or too little.
Package management needs to grow up, and recognize the experimenter's needs: add tools at whim, try it a while, and remove it.
One: If you're not an expert, and want to play with a package for a bit, see if one is produced by your distribution first. Failing that, then see if someone's made a package intended for your version of your distribution. Unless you're going to spend the time reading the source code, it's usually a waste of time and energy to rebuild a package, and it'll be less compatible with your distro anyway.
Two: If you manage a package, and your program can use X or libaudio or whatever but doesn't absolutely require it, then consider making two packages or making your program smart enough to use what's present at runtime, rather than blindly depend on it being present at installation time.
Three: The key to user-interface design is that the interface needs to understand the user. Not the other way around. Focus on the needs of the expected types of user: neophyte through master. If you're new, --help and RTFM aren't enough. Don't just teach the user to fulfill the tool's needs, teach your tool to anticipate the user's goals. Don't just teach people to use RPM directly, but instead provide smooth tools that use RPM behind-the-scenes.
This has gotten longer than I expected; I'd appreciate constructive replies.
Just think, someday I can "sing" the words along with the music, and due to their nifty software it will sound exactly as if I had the CD in.
Defendent:
alias Kraegar
Prosecutor:
United States,
Hilary Rosen, RIAA, et al
Charges:
Distribution of Method for
Circumvention of Copyright
Pursuant to DMCA
The claims by conservative Christian groups that gamers commit suicide or engage in criminal acts do not appear to hold water:
Michael Stackpole calculated expected suicide rates by gamers during the early years of Dungeons and Dragons. He used B.A.D.D.'s estimate of 4 million gamers worldwide. Assuming that fantasy role game playing had no effect on youth suicide rate, one would have expected about 500 gamers would have committed suicide each year. As of 1987, B.A.D.D. had documented an average of 7 per year. It would appear that playing D & D could be promoted as a public health measure, because it would seem to drastically lower the suicide rate among youth.
Emphasis mine.
A social game means you're dealing with people. Sometimes that means you despair over a bad relationship, but despairing over loneliness is a far greater risk.
Slashdot Mirror
the revolutionary DiscT@2TM Laser Labeling System,
...pronounced as Disc Tattoo Laser Labeling System.
[Google doesn't show a German word for tattoo.] A tattoo is a permanent marking by stippling ink designs into living skin. Or in this case, a permanent marking by stippling burn designs into compact disc designs.
Stupid ASCII Rebus puzzles. Leet Speek trademarks.
I mean, renaming a file to a new directory by pointing your finger is fine if you just want to rename one file. But to suggest that this is an improvement over the command line if you've got thousands of files to shuffle around is completely ignoring the computer's ability to do mind-numbing repetitive jobs quickly and accurately.
Finger gesturing interfaces are not meant for tasks like renaming files. You're right. If someone were to try to implement that, it would be laughable. But personally, if we start using finger pointing gestures to control computers, I would hope that the mere notion of filenames are irrelevant if not antiquated. Spatial gestures for spatial problems, text descriptions for text problems.
Now, use a command-line interface to sort a thousand stock photographs according to whether they're appropriate for your latest advertising campaign, or to determine if a polyketone molecule could theoretically wiggle through a hole in a proposed crystalline lattice. Massively complicated code or a few seconds of human mindpower? I've got your finger gesture right here.
I went MicroPro.com earlier this year because they had low prices and most of the parts I wanted.
This is how they treated my order. Two computers, pretty much ripped apart into pieces because they didn't even bother TRYING to pack the parts properly. The photos show how laughable their efforts were. Laughable if it's not your order, that is.
While they did eventually replace all the parts, they (1) were hoping to get away with calling it UPS's fault, and (2) took a month to "find" the RMA parts so they could replace it.
It was only the day I threatened a BBB letter that the final RMA'd units were mysteriously "found" and replaced promptly.
I wonder why so many people choose teddy bears for their projects.
teddy bear spy camera
teddy bear network switch
teddy bear terror bomb
Strange geek fetish?
I always thought that Gandolf looked a bit like Richard Stallman.
GNU/Gandolf, please.
Oh, the horrors. That one little misspelling, and now all of Tolkien's works will be forgotten. (It's Gandalf.)
The reason that it's hard to infect a Linux (/Unix/anything with a decient permission structure) system is that hardly anyone runs daily activities as root and only updates their /bin, /usr/bin, etc binaries from a known source or from source code.
While that may seem logical and common-sense to you, this is NOT obvious and intuitive to a huge newcomer/dilettante population out there.
A typical conversation on IRC:
[root] ne1 4 a question???
[Speare] Hey, root, it's a security risk to
run IRC or any software as the root
user. Set up a normal account and
use the root account just for system
administration tasks.
[root] i been on linux since 5.2, dont lecture
[root] ne1 no why
Seems like the de-facto third thing that every newbie wants to do, right after their first Linux distro install, is to rebuild their kernel. Why? I have no idea.
Yet almost nobody tells them how to build the kernel as non-root, or put the source anywhere but in root-writable /usr/src/linux, or why they should just stick to the pre-built, pre-audited kernels from their distro provider.
If SOMEONE wanted to zombie a lot of clueless folks, they should just distribute "helpful" kernel-building scripts.
Linux isn't secure until users know what security is.
The very idea of "forcibly placing" ones work into the "public domain by law" is quite distasteful.
Um, that's exactly what a patent is, and does. You document your method in detail for all to see, and in exchange, you can decide who uses the method for a limited amount of time. After the patent expires, potentially everyone benefits from your documentation freely.
As a semi-pro graphics artist, I really hate proprietary stock image formats. I can understand their desire to curb rampant copying, but I also dislike the lack of interoperability.
One example is the SNX format used by the Second Nature company for their screen saver images. I've purchased the discs, I would like to use them on Linux, not the native Windows.
A worse example is the Hemera HPI format used for their stock "photo objects." These are 8 CD sets of about 50,000 images in a proprietary 24bpp + alpha channel format. Something which TIFF or PNG formats handle very well. Every time I want to use an image, I have to load up Windows, use their proprietary image search and export tool.
It's my estimation that in the long run, inconvenience added through proprietary "protections" will cost these royalty-free image companies far more sales than the illicit warez-ing of their content. And what happens when those stock companies are not around to support their proprietary converters? One Windows update and users are cut off from the image libraries which should be simple to access.
How much do you want to bet that 45 percent gap is freeware and/or open source?
I'd much rather wager that the 45 percent gap is the group of people who don't know what "copyright" is, beyond a vague sense that it's the little © symbol that's pictured next to the Hamburglar characters on a McDonald's placemat cartoon.
GMR (giant magnetoresistance) harddisk technology will not achieve terrabit-per-square-inch densities. Experiments with EMR (extra-ordinary magnetoresistive), which exceeds 100Gb/in^2 have been successful in the lab.
After that, comes IMR (improbable magnetoresistive) where the Library of Congress fits in a square inch.
Finally, new advancements in subatomic physics leads to LMR (ludicrous magnetoresistive), giving more bits of storage than there are atoms on the platter. The "flavor" and "color" of each quark are directly manipulated and sampled by the drive head.
Of course, I'm sure the RIAA will get them shut down ASAP to prove they own the right to every aspect of our culture, including our own commentary upon that culture.
Only if those online dictionaries happen to be member organizations under the RIAA umbrella. As far as I know, they are not. The RIAA doesn't sue when someone steals a car, the RIAA doesn't sue when someone steals a loaf of bread, the RIAA doesn't sue when someone steals a copy of Microsoft Excel.
Will the dictionary companies sue? Only if they think this causes them damage. That could be a matter of corporate image [claiming the voice is a recognizable de facto trademark of a specific dictionary property], a matter of competitive advantage [claiming the compilation of words constitutes an alternative product employing their own patent-protected methods], or a matter of creative control [claiming the specific aggregation of pronunciations or the specific voice actor's performance is an artistic expression that others have no inherent right to copy]. I think each of these claims are weak in this case.
We have three cases here.
There is an excellent book by Larry Gonick and Art Huffman to cover this last area. http://www.amazon.com/exec/obidos/ASIN/0062731009 It goes from understanding simple Newtonian and extended body stuff, magnetism and flux, electrical current, to quantum electro dynamics.
It is from this book that I finally grokked *why* a gyroscope will precess or rotate its axis when the axis is not aligned against gravity.
Is that the same sort of futuristic technology that many table lamps have had for, oh, forty years?
My apartment complex management requires the use of stove bombs. They are magnetically mounted to the overhead stove hood, and are about the same size as a can of sterno. An out-of-control stove fire would crack the can's fragile bottom, dumping a load of fire-retarding powder all over the top of the stove.
The recording industry hopes to standardize the entire computing industry on crippled hardware, nonstandard formatting for media, and to have taxpayer-funded anti-piracy enforcement squad. When the economy dips, the recording industry screams about the few percentage points of lost revenue through piracy.
The software industry, by comparison, have established open modular interfaces for stock hardware, has eliminated nonstandard formatting for media, and has a self-funded anti-piracy enforcement squad. Whether accurate or not, industry figures suggest that about a third of all software in use is pirated.
The recording industry is screaming about the impending doom for their business. I think that their approach is demonstrably bad for their business.
Microsoft (as an industry flagship) has enough liquid assets to buy all the gold in Fort Knox four times over. This isn't counting the intellectual property nor tangible property. I think that approach worked well for them.
Make the prices reasonable, even if the product is crappy, and the masses will flock to the cash registers.
The reverse is far more true, looking at the prices. A body not on a segway stays not on a segway unless presented with sufficient coinage.
The article lists these issues as why Free Software UI sucks.
Hello? Where is the #1 reason?
Sure, developers write things for themselves. Developers write things for their co-workers. But do developers of Free Software really go out and research the goals of their users?
In looking at Linux user interfaces, I see that most tools merely tie some toolkit strings onto the underlying code so that it can be manipulated. The current thinking seems to be that if the underlying driver can do something, expose that ability directly on the command line or in a preferences dialog box.
A great case-in-point is cd-burning software. Type (cdrecord --help). The typical GUI wrapper is just the Gtk equivalent of (cdrecord --help). A massive soup of options with little help for people who don't know what a leadin is, don't care what a TOC is, don't understand how the lovers Romeo and Joliet got into CD-burning, and don't understand whether they want to fixate the disc or not.
Instead, turn it over.
Make some archetypical example users of your application. Nate the newbie. Seth the secretary. Judy the junior admin. Devin the developer. Whoever it is that needs your help to accomplish their goals, get to know these people.
A useful CD burning tool doesn't need to expose everything the driver can do. Add music files here. Add data files or folders here. Might you want to add more files at a later date? Burn the disc.
In Alan Cooper's words, "don't make the user feel stupid."
A user interface needs to start with the user, and proceed to the interface.
PC Fashionistas exclaim, "Black is the new Beige!"
I sure hope we're not going to read an article two weeks from now which explains some computing error, and how the new fashionable color is actually something one could describe as a dusty mint color.
And please don't let them correct themselves again claiming that it's chic to use a sort of salmon/melon/peach color. I couldn't stand to boot up a computer of which the casing reminded me of tuna sashimi.
Maybe they aren't working for the same goal after all...
They have exactly the same goal, they just haven't fired the opening salvo of the cross-discipline battle yet. "There can be only one!"
Debian does distinguish between dependency management and package management.
Aye, I understand the dpkg tool. But who uses it directly? Not too many users, and not very often. Debian doesn't focus on the distinction, and leads people to a standard front-end: apt-get.
While I like the promise of RPM, its various front-ends like up2date and redcarpet are either limited to a small source-base or are unstable due to their lax standards-checking. The RPM tools will improve, and .deb and .rpm already learn the best practices from each other over time. I stick to RPM because I stick to Red Hat.
I use Red Hat. I love the up2date tool, especially the push-down email notifications, and prefer Red Hat built packages. However, up2date and its ilk need to develop strong linting tools and 'tainted' flags for those packages that haven't been independently validated, much like the .deb process is.
Why Red Hat instead of Debian then? Personal preference, based on the personalities in the community, the corporate backing, and the currentness of the development efforts.
The leadin says that Gentoo eliminates all that RPM dependency hell. I agree, that's how most newcomers to the RPM scheme see it. A lack of higher tools and a lack of understanding has left many a new RPM user crying in frustration.
I haven't used Gentoo yet, and it may be the greatest thing since sliced bread. In the interests of helping newcomers who try RPM-based distros, however, a couple of points...
RPM is a package format, and rpm is the low-level tool that deals with those files. If you use rpm directly, you'll have to deal with the deluge of interconnecting dependencies yourself. However, it was not designed to be the sole front-line tool, it's the workhorse.
Unlike the Debian strains which all adopted the apt-get tool, each RPM-based distro has gone their own way with dependency management. Debian doesn't seem to focus so much on a distinction between dependency management and package management.
This dependency management is typically the commercialized aspect of the commercialized distro market: pay a value-added subscription fee for the ease of using a simplified network based package update/installer as a service, as well as some preferential bandwidth considerations. Faster downloads, push-down email notices, scheduled automatic installations, and other value-added services are attractive to corporate and casual users.
Service tools like up2date, redcarpet, and the like are the intended front-ends that use the rpm mechanisms to seek, download, validate, and install packages.
Much of the problem with package systems, rpm or deb, lies in the unorganized and untested packages produced haphazardly by small project folks, and the ad-hoc installations by casual users. The end users try rpm directly, or the weak gui equivalents, and at the first sign of dependency problems, they start using --nodeps or --force. Paraphrasing Asimov, "--force is the last refuge of the incompetent." The surest way to bollox an RPM machine is to --force a few packages or remove them with --nodeps, leaving a patchwork of unsatisfied dependencies. The surest way for a package maintainer to encourage such destruction is to blindly make packages that depend on too much, or too little.
Package management needs to grow up, and recognize the experimenter's needs: add tools at whim, try it a while, and remove it.
One: If you're not an expert, and want to play with a package for a bit, see if one is produced by your distribution first. Failing that, then see if someone's made a package intended for your version of your distribution. Unless you're going to spend the time reading the source code, it's usually a waste of time and energy to rebuild a package, and it'll be less compatible with your distro anyway.
Two: If you manage a package, and your program can use X or libaudio or whatever but doesn't absolutely require it, then consider making two packages or making your program smart enough to use what's present at runtime, rather than blindly depend on it being present at installation time.
Three: The key to user-interface design is that the interface needs to understand the user. Not the other way around. Focus on the needs of the expected types of user: neophyte through master. If you're new, --help and RTFM aren't enough. Don't just teach the user to fulfill the tool's needs, teach your tool to anticipate the user's goals. Don't just teach people to use RPM directly, but instead provide smooth tools that use RPM behind-the-scenes.
This has gotten longer than I expected; I'd appreciate constructive replies.
A speedometer measures a proxy for the current traveling velocity, namely, drive train rotational velocity.
An odometer measures a proxy for the total distance traveled regardless of time.
If you want to trigger something once per mile traveled regardless of time, isn't the odometer what you would use?
Just think, someday I can "sing" the words along with the music, and due to their nifty software it will sound exactly as if I had the CD in.
Defendent:
alias Kraegar
Prosecutor:
United States,
Hilary Rosen, RIAA,
et al
Charges:
Distribution of Method for
Circumvention of Copyright
Pursuant to DMCA
Yeah, the D & D suicide attacks are specious, and we know it. Lawyers fight for their clients, not for the truth.
http://www.religioustolerance.org/d_a_d.htm
Michael Stackpole calculated expected suicide rates by gamers during the early years of Dungeons and Dragons. He used B.A.D.D.'s estimate of 4 million gamers worldwide. Assuming that fantasy role game playing had no effect on youth suicide rate, one would have expected about 500 gamers would have committed suicide each year. As of 1987, B.A.D.D. had documented an average of 7 per year. It would appear that playing D & D could be promoted as a public health measure, because it would seem to drastically lower the suicide rate among youth.
Emphasis mine.
A social game means you're dealing with people. Sometimes that means you despair over a bad relationship, but despairing over loneliness is a far greater risk.
What else can be detected by urine samples? And when will the toilet be on the home or world network? Open up your browser to read From: potty emails.