There is almost no relationship between "We Can Remember It For You Wholesale" and Total Recall. None of the story even takes place on Mars, there's just a bit of backstory at the end.
The first part of the movie is there intact, but just as the movie has extra twists,
so does the (very) short story.
Both are extremely cool, only in slightly different ways.
If you want to read very good Dick SF, start with the short story "The Electric Ant" and the novels *The Three Stigmata of Palmer Eldritch* and *The Man in the High Tower*.
I never cared much for The Man in the High Tower.
My favorites are currently A Scanner Darkly,
The Three Stigmata of Palmer Eldritch,
A Maze of Death and
The Game-players of Titan.
And the short stories are, in general, even more worthwhile.
The Electric Ant yes; but also
Faith of our Fathers (what a fucked up story!),
A little something for us temponauts,
The Golden Man,
the one with the Printers
and dozens of others.
There's a "The collected short stories" paperback series;
that's probably the best introduction to PKD.
Could it be that most digital natives are of a younger generation who feel the world should be handed to them and they also feel they have no need to learn anything except that which is of interest to them forcing the rest of the world to conform to their lack of motivation?
That, and the bizarre inferiority complex librarians seem to have.
It's as if they don't know how important their mission is.
And it's not really new.
My local public library started doing weird things circa ten years ago --
like placing PCs among the bookshelves where the kids sit
and play games all day long.
"IT projects" in general seems to be what libraries concentrate on,
or at least what makes the news.
Lending DRM-infested "e-books" and so on.
Having a great collection of books and a helpful staff isn't newsworthy,
thus it's not good PR, thus it isn't important.
See Cliff Stoll's Silicon Snake-Oil for a longer rant/an analysis.
And you can't hire Linux people because there is no Linux people, there are Fedora, RHEL, Suse, Ubuntu, Kubuntu, BSD, FreeBSd,Openbsd people, etc, etc. And the "linux" crowd tends to rush off on whatever the latest trend is, remember when Caldera Open Linux was trendy? Now it's Ubuntu, whoops, Kubuntu, whoops, linspire, whoops now back to Fedora. Like little kids running after the shiniest candy.
And no they are not all 'the same'. They have wildly different directory structures, gui, lib version, kernel version support options, kernel versions, etc.
Bullshit.
They are, for practical purposes, the same.
Why should you, or any normal Unix user, or programmer for that matter,
care about directory structures, versions of libraries or kernel versions?
And what's so "wildly different" about them anyway?
In which Linux distro isn't/etc called/etc,/usr/bin/usr/bin, and your home directory $HOME?
As for GUIs, I wouldn't know because I always tear away that trash and
use (c)twm as my "GUI".
But I see some of my colleagues using something flashy
starting with a K and some using something starting with a G,
on the same server. Some use ssh clients from Windows or Solaris.
And surprise, the world hasn't collapsed yet.
In fact, there haven't even been any dumb managers screaming
"But it isn't exactly the same everywhere!".
And as someone else more or less noted,
any decent Unix administrator can handle any Linux, *BSD or Solaris
(don't know about AIX...)
There are general principles, manpages and Google.
Decent administrators are by definition literate, and good troubleshooters.
Back in the late '90s I was infected by my first virus. I had never connected to the internet, I had just used the library and school computers. Somehow, I still managed to get a virus on my floppy diskette.
Sheesh, I forget so easily, but now that you mention it... Viruses of that nature had been around since the late-80s.
It sounds laughable now, but they were actually a real problem on the likes of the Amiga and Atari ST during the early 90s. No network required; the Amiga ones resided on the floppy boot-sector and could survive a warm reset.
Floppy-based viruses were an equally big problem on DOS PCs,
although I think they didn't usually use the boot sector.
That the grandparent got one from a school or library computer doesn't
surprise me the least. PCs in schools were (are?) filled to the brim
with viruses.
One thing many open source projects are lacking is good, solid documentation.
Not in my experience. If there are man pages, they tend to be good.
I tend to ignore flashy GUI things named {k,g}* though, so maybe it's worse there.
In fact I know it is -- the RHEL5 server at work doesn't even have
man pages for those funky things people overload it with; I have to google
for the process name to find out what the heck "metacity" is
and why everybody runs it.
If you pick a project, but don't want to/don't know how to jump right into coding, download the code. Read it over. Document it (comments, docs, faqs, whatever). You'll get to know the code in and out, and in doing so, probably figure out some way to contribute.
Fine, but if so, remember that this would be mostly a learning exercise.
If you contribute patches which just add comments to the source code,
you probably won't be popular.
Removing or fixing incorrect comments should be accepted though, and
so might documenting a block of very tricky code which noone dares to change.
My first complaint is their lack of 64-bit support. I'm running the AMD64 version of Debian, and Opera is (was) the only 32-bit program I had to run, making it a pain to keep a bunch of 32-bit compatibility libraries around for one program.
I hate that, too.
I think 64-bit is popular enough now that it'd be worth the time to compile for it. Given the large number of platforms Opera runs on, it should be pretty easy to port.
When asked on news:opera.linux, one Opera developer claimed they had problems with the renderer
on 64-bit. Maybe the Sparc and PPC ports are 32-bit?
Anyway, they are supposedly planning to release an AMD64 port now.
I forget exactly when, but there are rumors of alpha builds.
And yes, it is a couple of years late -- but better late than never.
Opera used to have an advertisement area on the right side of the toolbar, now a blank area.
When I paid them $$ back in 2000 or so, I could use that former ad-area
immediately. It used to be at the top right for me.
You may have a problem with your preferences: dragging around the toolbars
and hotlists and whatnot, plus taking Opera a few slightly incompatible upgrades,
may mess up those preferences. What happens if you rename your ~/.opera directory
temporarily while restarting Opera? Do you still have a blank area?
I favor mentioning a browser that respects my software freedom over those that don't (Opera, MSIE). This is the chief reason why I'll continue to run Firefox and Konqueror even if Opera flawlessly implements all CSS3 selectors.
I took the RMS Kool-Aid too, but in this case I make an exception.
Opera and John Bradley's xv are the only two non-free applications
I ever use at home.
Firefox feels like an alpha test release of something that might
eventually become a web browser one day. Possibly I would become used
to it over time, but... well. And Konqueror depends on ~60
other packages which I don't intend to install.
("kdemultimedia-kio-plugins"?)
I mean, if you're going to do it all afresh - why use UNIX?
Because if someone, post-1995, released a new, general-purpose OS that wasn't Unix-compatible,
everyone would laugh themselves silly.
If you are a Unix system, you are part of a family --
there are gigabytes of useful source code to port, and
there are plenty of nice ideas to work from or expand upon.
If you're not a Unix, you are alone. At least until someone takes
pity on you and writes a Unix compatibility layer...
You're assuming you have to freeze someone. If you could find a way to simply slow life processes down to the point where the subject hibernates for the trip (maybe losing a few years of normal life in the process) you might still have a winner. That's how Clarke envisioned most of the crew of the Discovery making the trip in 2001: A Space Odyssey, although the idea was to conserve resources, not extend their lifespan.
Clarke was not first, of course.
Some of the posters seem to think SF authors are all about warp speed and phasers.
In fact, the idea that space travel is horrible and/or slow has spawned a lot of interesting stories,
from (I assume) the 1940s until now.
Cordwainer Smith's The Lady Who Sailed The Soul
and Scanners Live In Vain come to mind.
And Theodore Sturgeon's Bulkhead.
it just makes the entire system seem antiquated and stupid if you tell people that's how to code stuff in Linux. "Here's this crappy text-based editor, and then you can use these other command line tools to compile and then debug your program in text mode. Linux is pretty advanced!"
IMNSHO, IDEs are overrated monolithic crap which wouldn't even exist if
MS-DOS had had multitasking and didn't suck so much (Turbo Pascal and so on...).
You mean when people ask me, I should lie and say
"This neat, flawless program? Oh, I created it using Eclipse 0.1986 and the Blazemonger,
C++ Elite Pro and SugarFish plugins. They're awsome! Linux rulez!" when in fact I "just" used
emacs, a shell prompt or two and a handful of standard Unix tools?
You need to know about kernel internals to start writing programs on Linux? Sure - maybe if you start your programming on Linux by writing device drivers.
That's what I thought, too.
But it is possible that that's just marketing-speak for the kinds of things
Stevens covered in Advanced Programming in the UNIX Environment.
Concepts like file descriptors, signals, fork(2) and exec*()...
If so, I think it's a good thing that it's in there.
If they re-implemented perl in java and could decisively show that "most perl benchmarks are faster in jperl than perl" then I would be interested. Until that day C/C++ will remain a faster language.
Doesn't it ever stick?
There is no language called C/C++.
And remember that a perl or Python interpreter is extremely and unusually
painful for old malloc().
There is no good way to statically structure your allocations in
a neat and efficient way. And you can't place the users hashes on the stack;
everything must go on the heap.
So, unless your perl interpreter does the same kind of things a JVM does,
an interpreter written in one of those other languages might win.
Vim is what I like in real life - quick (way faster than emacs), not-bloated (still in MBs)
Accusing either of them of being slow or bloated, today, is silly.
They're both tiny speed monsters compared to the bloatware everyone seems to run
(Gnome, KDE, Firefox, bloody Eclipse...)
Since the GP was using Ubuntu, do sudo apt-get install xkeycaps for a great program to make the remapping easy without having to worry about xmodmap tweaking.
Huh? xkeycaps isn't Ubuntu-specific,
and remapping Caps Lock is such a common task it's a one-line command in xorg.conf/XFree*.conf:
Option "XkbOptions" "ctrl:nocaps" and so on.
If CVS was so good, there would not be an army of people behind SVN.
If CVS was so good, there would not be an army of people using MS SourceSafe..?
OK, CVS sucks.
But it sucks in well-defined and well-known ways.
That's enough for me and many others, for the things we do.
Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 1
Exactly. With a centralized version control system (PVCS [...]) I've used in the past at a large company, everyone ended up making several different local copies of the code with various changes, in order to revert if necessary. I was dumbfounded - isn't that what version control is for, to keep track of changes?
That doesn't have to do with centralized/distributed.
ClearCase is super-centralized, but you do your experiments in branches, as many as you like.
When I supported life science researchers, not only was MS Word the standard, but we had a site license for EndNote. Does LaTeX have a similar plugin or ability?
It has BibTeX for handling citations and references, if that's what you mean.
But you don't need site licenses (or the concept of a "site") to use it, and noone
calls it a plugin.
It is not difficult to justify parallel programming. Ten years ago, it was difficult to justify because most computers had a single processor. Today, dual-core systems are increasingly common, and 8-core PC's are not unheard of. And software developers are already complaining because it's "too hard" to write parallel programs.
A common argument, but it doesn't make sense to me.
To justify it, you must identify a need.
What you mentioned (SMP machines in widespread use) is just something that makes it possible. It doesn't justify anything.
It's almost as if people think there is a moral need for every program to use
up all processing power in any machine. There isn't.
(Fortunately, because we'd need
very fast disks and networking for that vast majority of programs which are
I/O bound).
You are not alone, but I think the problem is intrinsic (or nearly so). VC is one more thing you have to worry about that is not actually doing your work.
If it isn't about doing your work, then why do you do it?
Of course it is about doing your job.
If you're a programmer,
it's analogous to asking your C compiler not to suppress warnings.
You would have to find those bugs anyway,
and you would do a much worse job without the help.
In my work, version control (or whatever fancy name ending in "management"
you like to put on it) relieves me of enormous burdens.
It lets me do separate work in isolation.
It lets me plan and replan my work, reschedule so that feature B gets delivered
before feature A.
It lets me review other people's changes, and it lets others review mine.
It lets me track the root cause of a bug, created years ago.
It lets me know exactly what I delivered to some poor guy.
Note though that you need more than a tool.
You need to have a common view on how to use it in your environment.
And you cannot have people who think it's useless non-productive non-work,
because they won't care -- and quite soon they will turn it into
useless non-productive non-work by taking "a few shortcuts" which negate
all the positive effects of version control, making it analogous to
wearing an expensive Armani suit and leaving the fly open.
Slashdot Mirror
The first part of the movie is there intact, but just as the movie has extra twists, so does the (very) short story. Both are extremely cool, only in slightly different ways.
I never cared much for The Man in the High Tower. My favorites are currently A Scanner Darkly, The Three Stigmata of Palmer Eldritch, A Maze of Death and The Game-players of Titan. And the short stories are, in general, even more worthwhile. The Electric Ant yes; but also Faith of our Fathers (what a fucked up story!), A little something for us temponauts, The Golden Man, the one with the Printers and dozens of others. There's a "The collected short stories" paperback series; that's probably the best introduction to PKD.
That, and the bizarre inferiority complex librarians seem to have. It's as if they don't know how important their mission is.
And it's not really new. My local public library started doing weird things circa ten years ago -- like placing PCs among the bookshelves where the kids sit and play games all day long. "IT projects" in general seems to be what libraries concentrate on, or at least what makes the news. Lending DRM-infested "e-books" and so on. Having a great collection of books and a helpful staff isn't newsworthy, thus it's not good PR, thus it isn't important.
See Cliff Stoll's Silicon Snake-Oil for a longer rant/an analysis.
Bullshit. They are, for practical purposes, the same.
Why should you, or any normal Unix user, or programmer for that matter, care about directory structures, versions of libraries or kernel versions? And what's so "wildly different" about them anyway? In which Linux distro isn't /etc called /etc, /usr/bin /usr/bin, and your home directory $HOME?
As for GUIs, I wouldn't know because I always tear away that trash and use (c)twm as my "GUI". But I see some of my colleagues using something flashy starting with a K and some using something starting with a G, on the same server. Some use ssh clients from Windows or Solaris. And surprise, the world hasn't collapsed yet. In fact, there haven't even been any dumb managers screaming "But it isn't exactly the same everywhere!".
And as someone else more or less noted, any decent Unix administrator can handle any Linux, *BSD or Solaris (don't know about AIX ...)
There are general principles, manpages and Google.
Decent administrators are by definition literate, and good troubleshooters.
Floppy-based viruses were an equally big problem on DOS PCs, although I think they didn't usually use the boot sector. That the grandparent got one from a school or library computer doesn't surprise me the least. PCs in schools were (are?) filled to the brim with viruses.
Not in my experience. If there are man pages, they tend to be good. I tend to ignore flashy GUI things named {k,g}* though, so maybe it's worse there. In fact I know it is -- the RHEL5 server at work doesn't even have man pages for those funky things people overload it with; I have to google for the process name to find out what the heck "metacity" is and why everybody runs it.
Fine, but if so, remember that this would be mostly a learning exercise. If you contribute patches which just add comments to the source code, you probably won't be popular. Removing or fixing incorrect comments should be accepted though, and so might documenting a block of very tricky code which noone dares to change.
I hate that, too.
When asked on news:opera.linux, one Opera developer claimed they had problems with the renderer on 64-bit. Maybe the Sparc and PPC ports are 32-bit?
Anyway, they are supposedly planning to release an AMD64 port now. I forget exactly when, but there are rumors of alpha builds. And yes, it is a couple of years late -- but better late than never.
When I paid them $$ back in 2000 or so, I could use that former ad-area immediately. It used to be at the top right for me. You may have a problem with your preferences: dragging around the toolbars and hotlists and whatnot, plus taking Opera a few slightly incompatible upgrades, may mess up those preferences. What happens if you rename your ~/.opera directory temporarily while restarting Opera? Do you still have a blank area?
I took the RMS Kool-Aid too, but in this case I make an exception. Opera and John Bradley's xv are the only two non-free applications I ever use at home.
Firefox feels like an alpha test release of something that might eventually become a web browser one day. Possibly I would become used to it over time, but ... well. And Konqueror depends on ~60
other packages which I don't intend to install.
("kdemultimedia-kio-plugins"?)
Because if someone, post-1995, released a new, general-purpose OS that wasn't Unix-compatible, everyone would laugh themselves silly.
If you are a Unix system, you are part of a family -- there are gigabytes of useful source code to port, and there are plenty of nice ideas to work from or expand upon.
If you're not a Unix, you are alone. At least until someone takes pity on you and writes a Unix compatibility layer ...
Clarke was not first, of course.
Some of the posters seem to think SF authors are all about warp speed and phasers. In fact, the idea that space travel is horrible and/or slow has spawned a lot of interesting stories, from (I assume) the 1940s until now. Cordwainer Smith's The Lady Who Sailed The Soul and Scanners Live In Vain come to mind. And Theodore Sturgeon's Bulkhead.
IMNSHO, IDEs are overrated monolithic crap which wouldn't even exist if MS-DOS had had multitasking and didn't suck so much (Turbo Pascal and so on ...).
You mean when people ask me, I should lie and say "This neat, flawless program? Oh, I created it using Eclipse 0.1986 and the Blazemonger, C++ Elite Pro and SugarFish plugins. They're awsome! Linux rulez!" when in fact I "just" used emacs, a shell prompt or two and a handful of standard Unix tools?
That's what I thought, too.
But it is possible that that's just marketing-speak for the kinds of things Stevens covered in Advanced Programming in the UNIX Environment. Concepts like file descriptors, signals, fork(2) and exec*() ...
If so, I think it's a good thing that it's in there.
The reviewer didn't seem to mention it but, yes, that aspect is covered. At least according to the Amazon blurb.
Doesn't it ever stick? There is no language called C/C++.
And remember that a perl or Python interpreter is extremely and unusually painful for old malloc(). There is no good way to statically structure your allocations in a neat and efficient way. And you can't place the users hashes on the stack; everything must go on the heap. So, unless your perl interpreter does the same kind of things a JVM does, an interpreter written in one of those other languages might win.
Accusing either of them of being slow or bloated, today, is silly. They're both tiny speed monsters compared to the bloatware everyone seems to run (Gnome, KDE, Firefox, bloody Eclipse ...)
Huh? xkeycaps isn't Ubuntu-specific, and remapping Caps Lock is such a common task it's a one-line command in xorg.conf/XFree*.conf: Option "XkbOptions" "ctrl:nocaps" and so on.
Assuming, of course, they are not already in their Proper Places (nowhere and to the left of A, respectively).
Damn. I've had call-last-kbd-macro bound to F8 for the past eleven years.
Thank you, I'll be using that phrase against a few Ubuntu-users I know.
And please let's not confuse that with the media itself. These cards should just be block devices in Unix-speak.
Sadly, this issue is completely under Microsoft's control. If Windows doesn't support it, it doesn't exist.
I wonder if Joliet or other intended-to-be-read-only file systems would work?
OK, CVS sucks. But it sucks in well-defined and well-known ways. That's enough for me and many others, for the things we do.
That doesn't have to do with centralized/distributed. ClearCase is super-centralized, but you do your experiments in branches, as many as you like.
It has BibTeX for handling citations and references, if that's what you mean. But you don't need site licenses (or the concept of a "site") to use it, and noone calls it a plugin.
A common argument, but it doesn't make sense to me. To justify it, you must identify a need. What you mentioned (SMP machines in widespread use) is just something that makes it possible. It doesn't justify anything.
It's almost as if people think there is a moral need for every program to use up all processing power in any machine. There isn't. (Fortunately, because we'd need very fast disks and networking for that vast majority of programs which are I/O bound).
If it isn't about doing your work, then why do you do it?
Of course it is about doing your job. If you're a programmer, it's analogous to asking your C compiler not to suppress warnings. You would have to find those bugs anyway, and you would do a much worse job without the help.
In my work, version control (or whatever fancy name ending in "management" you like to put on it) relieves me of enormous burdens. It lets me do separate work in isolation. It lets me plan and replan my work, reschedule so that feature B gets delivered before feature A. It lets me review other people's changes, and it lets others review mine. It lets me track the root cause of a bug, created years ago. It lets me know exactly what I delivered to some poor guy.
Note though that you need more than a tool. You need to have a common view on how to use it in your environment.
And you cannot have people who think it's useless non-productive non-work, because they won't care -- and quite soon they will turn it into useless non-productive non-work by taking "a few shortcuts" which negate all the positive effects of version control, making it analogous to wearing an expensive Armani suit and leaving the fly open.