"And just like you don't use oracle for storing data in real-time automotive transmissions, you don't use isam in 2005 for storing business data."
You may not. Many do. Given that your data model is either very simple or can always be ACCESSED in very simple ways, or performance is less of an issue than cost (e.g. the sub-optimal index-utilization is not an issue for you), everything else that differs between MySQL and most other RDBMSes is either server-side convinience or a nice optimization to have, but only applicable to niche users.
I'll be glad when MySQL has views. I'll also never use them, but it will shut up the people who whine about the lack of views. Transactions were a real concern for certain types of work (of course, individual statements were always atomic, as they must be for almost all real work), and I was glad to see them. I still never use transactions because I prefer to manage integrity at a higher level, but of course, there are times when the overhead of doing it that way would be prohibitive. Glad they're there.
Overall, I think the anti-MySQL camp these days is just reacting on reflex. They once had some valid points, but at this juncture, there's just trade-offs in feature sets, and performance is a DAMN IMPORTANT FEATURE.
"ok, how about using their non-isam option. Ok, now we've got the kind of data integrity we've taken for granted since about 1981."
No, WE have done no such thing. *I* and many others have done quite a few things since 1981 and relied on nothing so cumbersome.
I've worked with raw disk I/O; flat-files; single-key databases; and primative table-managers like MyISAM; more robust table managers like innoDB; pure time-series databases like fame; "enterprise" databases like Sybase and Oracle, etc. and they all have a broad appeal for different reasons.
"But, reads are very slow, often 1/10th the speed of myisam."
Yes, if you look up in the thread you will see discussion of the fact that you can trade performance for guarantees.
Of course, performance is not a constant across all usage patterns (just as compression is not a constant across all inputs). You have to choose your optimizations carefully, and sometimes the performance of your database doesn't even matter to you. Sometimes it's all that matters. Still... in most cases, you fall somewhere in the middle, and performance is one variable in a complex equation that also involves social, political, financial, and other technical variables.
"I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things."
First off, let's drop the word "script". It has no place in informed conversation, as it has no formal definition. Originaly the term meant logic-free execution of what would otherwise be command-line operations. Later, shells became capable of logic, so that definition wandered to include any run-time interpreted, high-level code which used existing programs to do its work. Then Perl came along and changed everything. Perl is non run-time interpreted, but it still feels "scriptish" in the sense that it is aware of the system its working with and makes its tools available to you.
Now languages exist across the spectrum from Perl to Ruby to Scheme to Java. They can all be called "scripting" languages if you want, but the term has lost its meaning. It's just a word that you use to refer to a language that you personally don't take seriously.
"Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it."
I liked the way Perl approached OO. It was a decidedly tentative approach. Where many languages added OO features by emulating C++ (the OO lingua franca of the early 90s), Perl didn't buy into that. It simply added all of the features that you would need to BUILD an OO system, but provided no object system, high-level OO abstractions, core library support, etc.
Now that choice is paying off. Perl 6 can look back acrosss the last 10 years and see all the ways that Perl's OO tools were used, and select the most successful strategies to codify into the language. Perl 6 is also pulling from other languages where their features have proven useful. So, for example, Ruby mixins work quite well, and Perl 6 will adapt into its object model.
"Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge;"
You clearly don't know Perl 6. The object system is a complete re-design and resembles a blend of some Perl 5 best practices, Ruby, and Smalltalk. It's NOT a pile of kludges at all (unless, as with "script", you'd simply like to continue using what you consider a derogitory word without any basis in fact).
"I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much)."
If whitespace scares you, you are doing yourself a disservice. I'm not terribly fond of Python, but it's not because of the whitespace thing. That was just difficult to get over at first, but we've all been writing pseudo-code using whitespace for blocking for decades, so it's not THAT hard to get used to.
"The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example)"
Well, for starters, there's no such thing as a "keys array" in either Perl 5 or Perl 6. You treat the return value of the keys method as an array in Perl 6, but to think of them as an array up-front is incorrect. That's probably the source of your confusion right there. You can do this in Perl 6:
$nkeys=%hash<subhash>.size
I'm sure you'll agree that that's not to hard to remember.
"and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character"
If you find @, $, % hard to type, then I'm not sure I can help you. You did say you'd been programming in Perl since the pink camel?
"Perl was only designed for the three data types, and adding more is a mess."
Here you're way off base. Perl 5 supports about a dozen data-types, but the most often used are:
Fluxbox is a window manager. Gnome is a desktop environment.
Please stop confusing the two. You can, quite legitimately, use fluxbox as your Gnome window manager (though its support for Gnome desktop APIs is only in its early stages), so saying that "Gnome was just a pig" doesn't say anything about fluxbox and its comparative performance.
Metacity, on the other hand (Gnome's default window manager) may or may not compare favorably to Fluxbox (I haven't tried a bare Metacity to compare against), but in using just a window manager, you lose all of the benefits of a desktop environment: session management, cross-application configuration parameters, uniform high-level drag and drop, etc.
You may not care about these things, but they are the core of a modern desktop environment, and have NOTHING to do with what window manager you select.
"If you're trying to get Linux and X running on a minimalist platform, small size suddenly becomes very important. Small size also implies fast, and if you're working on real-time graphics, that's a big plus."
Nope. First off, small size does not imply fast. Plenty of applications trade memory footprint for a speed gain (e.g. by keeping often used data in-core).
Second, real-time graphics depends on the X server, integrated hardware acceleration features and other non-window manager issues. There's really no window manager component in the performance of real-time graphics.
That was actually the beauty of the ICCCM: the job of the window manager as a client of the X server was isolated out, such that its duties were all user-driven. Your window manager doesn't HAVE to be small and/or fast in order for your applications to be.
Define decent. I use nautilus and get by just fine, so I'm not sure what feature you're asking for in particular. I could come up with a wish-list, I'm sure (and it wouldn't put a dent in the feature request list in Gnome Bugzilla, I'm equally certain).
"useable (system-wide) drag and drop"
I have no problems.
"homogenized toolkits (none of this "three apps, three different looks" bullshit)"
You can do that any time you want. There's no reason to ask (just an example) KDE and GNOME to go away because you like XFce. Just use the one you like, and don't use the others.
"a friendlier clipboard (I got a powerbook here, this whole THREE BUTTON MOUSE!!!!! thing is killin' me!)"
Apple has 3-button mice too, but for the powerbook, I'm sure they have some kind of gestures or other wiz-bang way to treat your mini-mouse as a real device.
"a non-shitty default aesthetic that doesn't compell me to change everything out of its sheer ugliness"
Themes are a dime a dozen. Please focus on things that are actually part of the desktop.
"a useful offline help system"
Yeah, well... I can't help you there. Just about every desktop has decided to roll their own rather than use established systems (info, man).
"CAREFULLY THOUGHT OUT CONSISTANT AND TESTED CONFIGURATION MENUS"
I've had no problems.
"and.... (pause for breath) everything else MacOS had in 1994"
If you like MacOS, stick with it. I prefer Gnome on top of FC3, but hey, it's your choice!
If you're interested, here's my password generator. Its default password generation (the -r option) is ok for most purposes, but if you want a really good password, the right thing to do is define your own pattern that describes a set of possible passwords in a syntax that's somewhat like a regular expression, and let it generate one for you. This involves you, so you're less likely to have to write it down, but if done correctly, allows for a very reasonable number of possible passwords.
"Would I use an intelligent grammar check? Yes, by all means. [... goes on to make suggestions...]"
What you're missing is the fact that this is one of the hardest problems ever tackled by computer science. Not only that, but even a moderate improvement over what MS does now would likely require an order of magnitude more code and run-time computation, making it inappropriate for most usage!
MS Word does an OK job of spotting the most common errors, but if you're better at it than MS Word is, just shut the thing off. There, no problems.
As far as writing something that you KNOW is incorrect... ok, so you get a green line under text that you already know is a problem, but you don't intend to change. No big deal. Why is this an imposition?
"Stargate [...] Battlestar galactica [...] Star Wars [...] all demonstrate the same repetition."
I won't be drawn into a straw-man. The observation in the grand-parent post was that TV SF has (the perception of) only room for one setting: Trek. That's clearly not the case, based on the examples I gave.
If you want to have a seperate discussion about the difficulty in pitching a unique idea in Hollywood, I'll take a very different stand, but on THIS point there is no debate: Babylon 5 broke the established Hollywood theory that there was room only for Star Trek in TV SF (JMS, creator of B5 was told this explicity and repeatedly while pitching the show), and that theory remains broken to this day with dozens of TV movies, mini-series and full series since to back up the claim.
"Enterprise failed due to overt similarity to Andromeda"
No. I'm sorry, but Enterprise failed because it had no decent stories until the fourth season. I watched the first few episodes, disheartened with Voyager, and wanting to see something new and interesting that would re-kindle my love of Trek. No joy. I recommended that many people not even bother after seeing the first two episodes, and I'm sure many other trekkies did the same.
"The one difference I think you're all missing is that all these films and series take place in a universe with a mature interstellar civilization"
I'd have to say that Battlestar Galactica definitely does not fit into that category, and while in Stargate, there are races that have been out there building civilizations since before humans were on the scene, this compares favorbably to ST:ToS where humans were just starting to explore the galaxy which many older races called home for millenia or even MUCH more (Organians).
Nope, I fail to see the lack of a sense of exploration in Battlestar Galactica or Stargate.
However exploration is NOT the only useful theme in SF, and ST:ToS is not the only valid recipie for good story-telling. For example, a series based on the Foundation trilogy or Dune would have almost no exploration component at all. Same goes for most of the Culture books and a fair chunk of Nivin's universe (though some of it WAS clearly exploritory... especially the earlier books).
"There's apparently so little writing ability and creativity in Hollywood that they can't get beyond Star Trek as the only possible metaphor for space-based Sci Fi"
Stargate (both shows), Battlestar Galactica, Star Wars: Clone Wars... these are just the good shows that I know something about.
Just how many space-based shows do there have to be to convince you?
A Starfleet Academy show or movie isn't such a bad idea. It is fertile ground for many sorts of story-telling, and could really re-vitalize the show.
Then again, so could any generic concept. Really. Let's try a few:
Star Trek: Trash Collectors -- A show focusing on a "grabage scow" that works in Federation space near the Klingon Empire between ST:ToS and ST:TNG. You could have stories that range from the discovery of ancient objects in the trash to slice-of-life stories that focus on what "normal people" do in the federation. The overall story arc should be a sort of behind-the-scenes story of the end of Klingon / Federation hostilies after movie 6.
Star Trek: Financial Planners -- Here's a story line I've always wanted. In a federation that says it doesn't have money, but in reality uses money in dozens of ways... how do you manage your financial security? This would be similar to your average legal show, with new cases each week and ongoing character drama. The catch is this: you get to bring in all of the folks from TNG and DS9 (perhaps even some Voyager people) as guest stars. I'd love to see Diana Troy angsting about how to deal with Worf's Klingon inheritance and shouting down Klingon reps who say that she can't be named an heir. There's good drama there.
Anything CAN work, the trick is telling good stories, and that's what Trek has been light on.
There are dozens of stories you could tell set in an Academy from the mystery sleuth ala Veronica Mars sorts of things to an Ender's Game like story-line. You could even do Top Gun: a bunch of hot-shots come from Federation training facilities all over to qualify for the Academy. You get to have a first season of intense character drama as the students vie for a fixed number of slots, and then the next four seasons are once they get in.
One thing that I think would be a huge mistake is this: don't use established characters in the lead roles. Bring in guests, sure, but don't have Star Trek: TOS characters show up as teen-agers. It's just too hard to pull off in a way that doesn't detract from the story you're telling.
What you MIGHT do is introduce several characters that are very similar to people we've known. Maybe even make some of them descendents of the people we know. But outright making them the same characters is a mistake.
Ideally, I think you want to set it after everything that we've seen in the main time-frame of the shows (that is, sometime between when Voyager leaves and when it comes back). This way, the story is wide-open and you can introduce any kind of intrigue you like.
"There are no other products. Gimp (which I prefer in many cases) can't do half of the things a professional graphic artist needs"
Depends on the artist between Gimp and Cinepaint (a gimp fork) many video editing houses use Gimp for single-frame edits because it's cheaper, lighter weight, and more easily customizable than PS.
"And when looking at photo editing, I havent' seen ANY product that has good RAW support"
I do all my RAW file editing using Gimp 2.2. There are plug-ins that you need, and a stand-alone RAW tool, but the documentation for installing is quite easy to follow, even for less advanced users.
There are also some camera-specific RAW tools that go a step beyond, taking advantage of many features which are extensions to the basic RAW file support.
"Yes I do believe I've heard of this 'rpm' thing, if I remember correct it all worked fine and dandy until 1 thing got installed from source or similar, and then it became a --nodeps hell."
This is akin to saying that everything works fine when using a hammer, right up until you buy glass nails. Simple solution: don't buy glass nails.
More to the point, if you have source for something, make an SRPM out of it, and install. If *that* were what this auto-packager did, it would be a wonderful tool. There are certianly many steps in the production of an SRPM which could easily be automated (detect common configuration tools, determine best way to find dependencies, etc.)
They could have even achieved their goal of cross-platform usefulness by making the RPM back-end modular so that DEB or Gentoo ports could be generated as well. Instead they came up with their own dependency tracker which is incompatible with the standard one used by the system.
Back to your point: When you start using --nodeps with RPM, you've already lost. I've been working with RPM for 5 years with packages local and standard, and have never had to force an installation without dependency resolution. It's all about knowing your tools. If you don't know your tools, then no fancy front-end is ever going to help you.
The FAQ demonstrates a profound lack of understanding of existing package managers. For example, many of the features (like location-neutral file dependencies) are standard features of RPM and (I think) DEB.
It strikes me that the only value in this tool is their attempt to produce a cross-platform package manager. Had they done this by auto-generating the deistribution-specific package information (e.g. a.spec file for RPM) based on some meta-information, then I would have said this is a good thing. After all, it would be nice to generate just one installation config file for all platforms and have platform integrators worry about makign that tool work once on system foo, rather than every new project repeating that work.
autopackage does not do this, however. It tries to run its own show, which means that you cannot mix-and-match with existing systems. For example, I might use RPM via APT. I find a new project for the fooerizer, and want to use it. I use autopackage to install it. However, next week my APT repositories pick up fooerizer and, not knowing that I have a more recent version already installed, trash my installation (in potentially incompatible ways).
The only thing I'd like to see in a package manager is to allow non-root users to install software
Check out the Flash demo. They actually demonstrate that capability-- the application installs packages under $HOME/.local/lib $HOME/.local/share, etc. I dislike cluttering $HOME with $HOME/lib, $HOME/share, $HOME/man, etc. -- installing these pieces under a dot directory to keep them hidden & organized is a great idea.
Also consider checking out this new tool called RPM. It's pretty slick, and although (based on the chatter here) no one has heard about it yet, it's pretty snazzy.
It includes post-installation and removal logic, non-root usage, installed package validation and many other features that people find useful.
The autopackage folks keep saying that autopackage isn't aimed at the same jobs as RPM, but what I'm getting is that it's aimed at jobs that they didn't think RPM could do... but it can, does and does well.
There are also several automatic RPM generators, though I usually find that only the domain-specific ones are worth the trouble (e.g. the CPAN RPMifiers). All of the others work great for the first day or week... right up until a package changes its dependency graph in an update, and suddenly conflicts with your auto-generated dependency graph.
There are two rules here:
Dependency management is hard
Making it easy is harder
In general, you end up wanting a human to directly manage dependencies, as a part of release engineering. If you don't have a release engineering step, then a spiffy package creator isn't going to solve your real problems.
Gopher is part of the World Wide Web, as are several other protocols that pre-date the Web. You meant to say, "This is why Gopher will always be better than an HTTP server."
The World Wide Web is the meta-index of (mostly) Internet-accessible content which can be addressed by URI (almost always more specifically by URL).
Since Gopher can be addressed via the URI scheme, "gopher", it's part of the Web.
There are many ways to deal with the problem of identifying a reverse-engineered copy of software. For example, you might use information that a person reverse-engineering would consider unimportant (seemingly uninitialized portions of the data stream, timing, out-of-band protocol information, etc.) If you're really smart, you then make your server accept all connections, wait for the usage to become popular and THEN kill all of the connections from reverse-engineered clients.
Alternatively, you can simply use TCP fingerprinting techniques to determine that the connection is coming from an OS that you have not ported your software to.
Actually, Perl is not an ideal language for obfuscated code. It has many special cases in the tokenizer (e.g. using a balanced character like [ with a quote-like operator causes it to search for the appropriate end-character like ], but using the end-character to start the quote is also possible and quite hard to read), which can be used to great effect in obfuscation, but then nothing in Perl compares to the unholy things you can do with the C pre-processor, as evidenced by Perl's tokenizer (which is written in C, and few people dare touch).
The major problem with obfuscating Perl is the "line noise". All of the funky extra syntax you have to throw into your code that makes newbies blanch actually makes it VERY hard to obfuscate code.
Of course, you can take advantage of the fact that people who don't know the language find it hard to read, so
$_=$/++
will certainly intimidate people not familiar with Perl, but for those who are, there's not only no obfuscation there, but a wealth of information about what is being done.
In short, Perl is a great language for writing code that people who don't write Perl consider obfuscated, but if you want to write code that even people well-versed in the language find difficult, you have to go to a language which has less redundant information available to the observer. It also helps to use a language in which you can trivially violate the grammar of the language by building your own syntax (e.g. the C pre-processor).
Yep, that's why you need -fwritabe-strings in gcc. Old C compilers (remember this was written almost 20 years ago) let you write to constant strings (that is to say, they weren't constant in the first place). MSVS probably has an option for this.
Slashdot Mirror
"And just like you don't use oracle for storing data in real-time automotive transmissions, you don't use isam in 2005 for storing business data."
You may not. Many do. Given that your data model is either very simple or can always be ACCESSED in very simple ways, or performance is less of an issue than cost (e.g. the sub-optimal index-utilization is not an issue for you), everything else that differs between MySQL and most other RDBMSes is either server-side convinience or a nice optimization to have, but only applicable to niche users.
I'll be glad when MySQL has views. I'll also never use them, but it will shut up the people who whine about the lack of views. Transactions were a real concern for certain types of work (of course, individual statements were always atomic, as they must be for almost all real work), and I was glad to see them. I still never use transactions because I prefer to manage integrity at a higher level, but of course, there are times when the overhead of doing it that way would be prohibitive. Glad they're there.
Overall, I think the anti-MySQL camp these days is just reacting on reflex. They once had some valid points, but at this juncture, there's just trade-offs in feature sets, and performance is a DAMN IMPORTANT FEATURE.
"ok, how about using their non-isam option. Ok, now we've got the kind of data integrity we've taken for granted since about 1981."
No, WE have done no such thing. *I* and many others have done quite a few things since 1981 and relied on nothing so cumbersome.
I've worked with raw disk I/O; flat-files; single-key databases; and primative table-managers like MyISAM; more robust table managers like innoDB; pure time-series databases like fame; "enterprise" databases like Sybase and Oracle, etc. and they all have a broad appeal for different reasons.
"But, reads are very slow, often 1/10th the speed of myisam."
Yes, if you look up in the thread you will see discussion of the fact that you can trade performance for guarantees.
Of course, performance is not a constant across all usage patterns (just as compression is not a constant across all inputs). You have to choose your optimizations carefully, and sometimes the performance of your database doesn't even matter to you. Sometimes it's all that matters. Still... in most cases, you fall somewhere in the middle, and performance is one variable in a complex equation that also involves social, political, financial, and other technical variables.
No one solution is right for everyone.
You can call it bloat or beneficial features. It's all a mater of perspective.
First off, let's drop the word "script". It has no place in informed conversation, as it has no formal definition. Originaly the term meant logic-free execution of what would otherwise be command-line operations. Later, shells became capable of logic, so that definition wandered to include any run-time interpreted, high-level code which used existing programs to do its work. Then Perl came along and changed everything. Perl is non run-time interpreted, but it still feels "scriptish" in the sense that it is aware of the system its working with and makes its tools available to you.
Now languages exist across the spectrum from Perl to Ruby to Scheme to Java. They can all be called "scripting" languages if you want, but the term has lost its meaning. It's just a word that you use to refer to a language that you personally don't take seriously.
"Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it."
I liked the way Perl approached OO. It was a decidedly tentative approach. Where many languages added OO features by emulating C++ (the OO lingua franca of the early 90s), Perl didn't buy into that. It simply added all of the features that you would need to BUILD an OO system, but provided no object system, high-level OO abstractions, core library support, etc.
Now that choice is paying off. Perl 6 can look back acrosss the last 10 years and see all the ways that Perl's OO tools were used, and select the most successful strategies to codify into the language. Perl 6 is also pulling from other languages where their features have proven useful. So, for example, Ruby mixins work quite well, and Perl 6 will adapt into its object model.
"Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge;"
You clearly don't know Perl 6. The object system is a complete re-design and resembles a blend of some Perl 5 best practices, Ruby, and Smalltalk. It's NOT a pile of kludges at all (unless, as with "script", you'd simply like to continue using what you consider a derogitory word without any basis in fact).
"I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much)."
If whitespace scares you, you are doing yourself a disservice. I'm not terribly fond of Python, but it's not because of the whitespace thing. That was just difficult to get over at first, but we've all been writing pseudo-code using whitespace for blocking for decades, so it's not THAT hard to get used to.
"The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example)"
Well, for starters, there's no such thing as a "keys array" in either Perl 5 or Perl 6. You treat the return value of the keys method as an array in Perl 6, but to think of them as an array up-front is incorrect. That's probably the source of your confusion right there. You can do this in Perl 6:
I'm sure you'll agree that that's not to hard to remember.
"and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character"
If you find @, $, % hard to type, then I'm not sure I can help you. You did say you'd been programming in Perl since the pink camel?
"Perl was only designed for the three data types, and adding more is a mess."
Here you're way off base. Perl 5 supports about a dozen data-types, but the most often used are:
Fluxbox is a window manager. Gnome is a desktop environment.
Please stop confusing the two. You can, quite legitimately, use fluxbox as your Gnome window manager (though its support for Gnome desktop APIs is only in its early stages), so saying that "Gnome was just a pig" doesn't say anything about fluxbox and its comparative performance.
Metacity, on the other hand (Gnome's default window manager) may or may not compare favorably to Fluxbox (I haven't tried a bare Metacity to compare against), but in using just a window manager, you lose all of the benefits of a desktop environment: session management, cross-application configuration parameters, uniform high-level drag and drop, etc.
You may not care about these things, but they are the core of a modern desktop environment, and have NOTHING to do with what window manager you select.
"If you're trying to get Linux and X running on a minimalist platform, small size suddenly becomes very important. Small size also implies fast, and if you're working on real-time graphics, that's a big plus."
Nope. First off, small size does not imply fast. Plenty of applications trade memory footprint for a speed gain (e.g. by keeping often used data in-core).
Second, real-time graphics depends on the X server, integrated hardware acceleration features and other non-window manager issues. There's really no window manager component in the performance of real-time graphics.
That was actually the beauty of the ICCCM: the job of the window manager as a client of the X server was isolated out, such that its duties were all user-driven. Your window manager doesn't HAVE to be small and/or fast in order for your applications to be.
"I want a decent file browser"
Define decent. I use nautilus and get by just fine, so I'm not sure what feature you're asking for in particular. I could come up with a wish-list, I'm sure (and it wouldn't put a dent in the feature request list in Gnome Bugzilla, I'm equally certain).
"useable (system-wide) drag and drop"
I have no problems.
"homogenized toolkits (none of this "three apps, three different looks" bullshit)"
You can do that any time you want. There's no reason to ask (just an example) KDE and GNOME to go away because you like XFce. Just use the one you like, and don't use the others.
"a friendlier clipboard (I got a powerbook here, this whole THREE BUTTON MOUSE!!!!! thing is killin' me!)"
Apple has 3-button mice too, but for the powerbook, I'm sure they have some kind of gestures or other wiz-bang way to treat your mini-mouse as a real device.
"a non-shitty default aesthetic that doesn't compell me to change everything out of its sheer ugliness"
Themes are a dime a dozen. Please focus on things that are actually part of the desktop.
"a useful offline help system"
Yeah, well... I can't help you there. Just about every desktop has decided to roll their own rather than use established systems (info, man).
"CAREFULLY THOUGHT OUT CONSISTANT AND TESTED CONFIGURATION MENUS"
I've had no problems.
"and.... (pause for breath) everything else MacOS had in 1994"
If you like MacOS, stick with it. I prefer Gnome on top of FC3, but hey, it's your choice!
Try out this default invocation to get started:or this one for the manuyal:Enjoy!
"Would I use an intelligent grammar check? Yes, by all means. [... goes on to make suggestions ...]"
What you're missing is the fact that this is one of the hardest problems ever tackled by computer science. Not only that, but even a moderate improvement over what MS does now would likely require an order of magnitude more code and run-time computation, making it inappropriate for most usage!
MS Word does an OK job of spotting the most common errors, but if you're better at it than MS Word is, just shut the thing off. There, no problems.
As far as writing something that you KNOW is incorrect... ok, so you get a green line under text that you already know is a problem, but you don't intend to change. No big deal. Why is this an imposition?
"Stargate [...] Battlestar galactica [...] Star Wars [...] all demonstrate the same repetition."
I won't be drawn into a straw-man. The observation in the grand-parent post was that TV SF has (the perception of) only room for one setting: Trek. That's clearly not the case, based on the examples I gave.
If you want to have a seperate discussion about the difficulty in pitching a unique idea in Hollywood, I'll take a very different stand, but on THIS point there is no debate: Babylon 5 broke the established Hollywood theory that there was room only for Star Trek in TV SF (JMS, creator of B5 was told this explicity and repeatedly while pitching the show), and that theory remains broken to this day with dozens of TV movies, mini-series and full series since to back up the claim.
"Enterprise failed due to overt similarity to Andromeda"
No. I'm sorry, but Enterprise failed because it had no decent stories until the fourth season. I watched the first few episodes, disheartened with Voyager, and wanting to see something new and interesting that would re-kindle my love of Trek. No joy. I recommended that many people not even bother after seeing the first two episodes, and I'm sure many other trekkies did the same.
"The one difference I think you're all missing is that all these films and series take place in a universe with a mature interstellar civilization"
I'd have to say that Battlestar Galactica definitely does not fit into that category, and while in Stargate, there are races that have been out there building civilizations since before humans were on the scene, this compares favorbably to ST:ToS where humans were just starting to explore the galaxy which many older races called home for millenia or even MUCH more (Organians).
Nope, I fail to see the lack of a sense of exploration in Battlestar Galactica or Stargate.
However exploration is NOT the only useful theme in SF, and ST:ToS is not the only valid recipie for good story-telling. For example, a series based on the Foundation trilogy or Dune would have almost no exploration component at all. Same goes for most of the Culture books and a fair chunk of Nivin's universe (though some of it WAS clearly exploritory... especially the earlier books).
"There's apparently so little writing ability and creativity in Hollywood that they can't get beyond Star Trek as the only possible metaphor for space-based Sci Fi"
Stargate (both shows), Battlestar Galactica, Star Wars: Clone Wars... these are just the good shows that I know something about.
Just how many space-based shows do there have to be to convince you?
A Starfleet Academy show or movie isn't such a bad idea. It is fertile ground for many sorts of story-telling, and could really re-vitalize the show.
Then again, so could any generic concept. Really. Let's try a few:
Star Trek: Trash Collectors -- A show focusing on a "grabage scow" that works in Federation space near the Klingon Empire between ST:ToS and ST:TNG. You could have stories that range from the discovery of ancient objects in the trash to slice-of-life stories that focus on what "normal people" do in the federation. The overall story arc should be a sort of behind-the-scenes story of the end of Klingon / Federation hostilies after movie 6.
Star Trek: Financial Planners -- Here's a story line I've always wanted. In a federation that says it doesn't have money, but in reality uses money in dozens of ways... how do you manage your financial security? This would be similar to your average legal show, with new cases each week and ongoing character drama. The catch is this: you get to bring in all of the folks from TNG and DS9 (perhaps even some Voyager people) as guest stars. I'd love to see Diana Troy angsting about how to deal with Worf's Klingon inheritance and shouting down Klingon reps who say that she can't be named an heir. There's good drama there.
Anything CAN work, the trick is telling good stories, and that's what Trek has been light on.
There are dozens of stories you could tell set in an Academy from the mystery sleuth ala Veronica Mars sorts of things to an Ender's Game like story-line. You could even do Top Gun: a bunch of hot-shots come from Federation training facilities all over to qualify for the Academy. You get to have a first season of intense character drama as the students vie for a fixed number of slots, and then the next four seasons are once they get in.
One thing that I think would be a huge mistake is this: don't use established characters in the lead roles. Bring in guests, sure, but don't have Star Trek: TOS characters show up as teen-agers. It's just too hard to pull off in a way that doesn't detract from the story you're telling.
What you MIGHT do is introduce several characters that are very similar to people we've known. Maybe even make some of them descendents of the people we know. But outright making them the same characters is a mistake.
Ideally, I think you want to set it after everything that we've seen in the main time-frame of the shows (that is, sometime between when Voyager leaves and when it comes back). This way, the story is wide-open and you can introduce any kind of intrigue you like.
"There are no other products. Gimp (which I prefer in many cases) can't do half of the things a professional graphic artist needs"
Depends on the artist between Gimp and Cinepaint (a gimp fork) many video editing houses use Gimp for single-frame edits because it's cheaper, lighter weight, and more easily customizable than PS.
"And when looking at photo editing, I havent' seen ANY product that has good RAW support"
I do all my RAW file editing using Gimp 2.2. There are plug-ins that you need, and a stand-alone RAW tool, but the documentation for installing is quite easy to follow, even for less advanced users.
There are also some camera-specific RAW tools that go a step beyond, taking advantage of many features which are extensions to the basic RAW file support.
"Yes I do believe I've heard of this 'rpm' thing, if I remember correct it all worked fine and dandy until 1 thing got installed from source or similar, and then it became a --nodeps hell."
This is akin to saying that everything works fine when using a hammer, right up until you buy glass nails. Simple solution: don't buy glass nails.
More to the point, if you have source for something, make an SRPM out of it, and install. If *that* were what this auto-packager did, it would be a wonderful tool. There are certianly many steps in the production of an SRPM which could easily be automated (detect common configuration tools, determine best way to find dependencies, etc.)
They could have even achieved their goal of cross-platform usefulness by making the RPM back-end modular so that DEB or Gentoo ports could be generated as well. Instead they came up with their own dependency tracker which is incompatible with the standard one used by the system.
Back to your point: When you start using --nodeps with RPM, you've already lost. I've been working with RPM for 5 years with packages local and standard, and have never had to force an installation without dependency resolution. It's all about knowing your tools. If you don't know your tools, then no fancy front-end is ever going to help you.
lose the fucking snot-nosed additude [...] LEARN SOME SOCIAL SKILLS
'Nuff said.
The FAQ demonstrates a profound lack of understanding of existing package managers. For example, many of the features (like location-neutral file dependencies) are standard features of RPM and (I think) DEB.
.spec file for RPM) based on some meta-information, then I would have said this is a good thing. After all, it would be nice to generate just one installation config file for all platforms and have platform integrators worry about makign that tool work once on system foo, rather than every new project repeating that work.
It strikes me that the only value in this tool is their attempt to produce a cross-platform package manager. Had they done this by auto-generating the deistribution-specific package information (e.g. a
autopackage does not do this, however. It tries to run its own show, which means that you cannot mix-and-match with existing systems. For example, I might use RPM via APT. I find a new project for the fooerizer, and want to use it. I use autopackage to install it. However, next week my APT repositories pick up fooerizer and, not knowing that I have a more recent version already installed, trash my installation (in potentially incompatible ways).
Also consider checking out this new tool called RPM. It's pretty slick, and although (based on the chatter here) no one has heard about it yet, it's pretty snazzy.
It includes post-installation and removal logic, non-root usage, installed package validation and many other features that people find useful.
The autopackage folks keep saying that autopackage isn't aimed at the same jobs as RPM, but what I'm getting is that it's aimed at jobs that they didn't think RPM could do... but it can, does and does well.
There are also several automatic RPM generators, though I usually find that only the domain-specific ones are worth the trouble (e.g. the CPAN RPMifiers). All of the others work great for the first day or week... right up until a package changes its dependency graph in an update, and suddenly conflicts with your auto-generated dependency graph.
There are two rules here:
Dependency management is hard
Making it easy is harder
In general, you end up wanting a human to directly manage dependencies, as a part of release engineering. If you don't have a release engineering step, then a spiffy package creator isn't going to solve your real problems.
Gopher is part of the World Wide Web, as are several other protocols that pre-date the Web. You meant to say, "This is why Gopher will always be better than an HTTP server."
The World Wide Web is the meta-index of (mostly) Internet-accessible content which can be addressed by URI (almost always more specifically by URL).
Since Gopher can be addressed via the URI scheme, "gopher", it's part of the Web.
You're just trying to be abstruse. ;-)
There are many ways to deal with the problem of identifying a reverse-engineered copy of software. For example, you might use information that a person reverse-engineering would consider unimportant (seemingly uninitialized portions of the data stream, timing, out-of-band protocol information, etc.) If you're really smart, you then make your server accept all connections, wait for the usage to become popular and THEN kill all of the connections from reverse-engineered clients.
Alternatively, you can simply use TCP fingerprinting techniques to determine that the connection is coming from an OS that you have not ported your software to.
The major problem with obfuscating Perl is the "line noise". All of the funky extra syntax you have to throw into your code that makes newbies blanch actually makes it VERY hard to obfuscate code.
Of course, you can take advantage of the fact that people who don't know the language find it hard to read, so will certainly intimidate people not familiar with Perl, but for those who are, there's not only no obfuscation there, but a wealth of information about what is being done.
In short, Perl is a great language for writing code that people who don't write Perl consider obfuscated, but if you want to write code that even people well-versed in the language find difficult, you have to go to a language which has less redundant information available to the observer. It also helps to use a language in which you can trivially violate the grammar of the language by building your own syntax (e.g. the C pre-processor).
You lost me at "?: is confusing"... how is a simple ternary logic operator confusing?!
Yep, that's why you need -fwritabe-strings in gcc. Old C compilers (remember this was written almost 20 years ago) let you write to constant strings (that is to say, they weren't constant in the first place). MSVS probably has an option for this.
Please, if you're going to snag the text, cite it:
Now the world has gone to bed,
Darkness won't engulf my head.
I can see by infra-red.
How I hate the night.
Now I lay me down to sleep,
Try to count electric sheep.
Sweet dream wishes you can keep,
How I hate the night.
Life, the Universe and Everything
by Douglas Adams, 1952-2001