All any company like VA does is take off-the-shelf OEM parts, slap a machine together, and glue a little plastic logo on the front of the case.
While there are many companies like that, VA is not one of them.
They know Linux, what it needs, and what it does. They specialize in Linux and Linux compatibility. This is more then I can say for Dell, Compaq, or HP at this point.
VA does a good deal of research and testing to make sure their stuff is Linux compatible.
VA provides Linux-specific documentation.
They do a fair amount of custom engineering when needed, especially in their low-profile rack-mount servers.
They give back to the Linux community quite a bit.
Now, none of this excuses poor customer service or quality, but your claim that VA is just another Intel PC VAR isn't true.
Youre not getting anything you couldn't otherwise assemble on your own, or obtain from a larger LInux systems vendor such as IBM, Dell, and others.
I think not.
HP: Other then in press releases, their hardware literature doesn't mention Linux, and you can't configure a system with Linux pre-installed on it. Doesn't look too promising to me.
Compaq: LOL. Their "Linux" page wants to sell you machines with Windows pre-installed. Give me a break.
IBM: I haven't dealt with IBM on Linux, but I have gotten the impression that, while serious about Linux, they are still ramping up to really support it well on their Intel lines. But at least they'll sell you a system with Linux on it.
Dell: Will sell you a system with Linux, and at least seems to be committed to it. But, they really have a ways to go. They will happilly bundle NT software with your Linux system, and wonder why you say you cannot use it. And their Linux driver support is iffy.
Would I buy a VA Linux system? Unlikely. Are they doing as good a job as they should? Maybe not. Are they as bad as you make them out to be? No.
Why are people buying prebuild crap from companies that treat them like crap?
Well, I don't know about anybody else, but I can talk about the company I work for.
We're a small-time integrator specializing in Linux. Even being small, we ship between two and ten servers a month. It is easier for us to pay someone else to build them for us then it is for us to build them ourselves.
And these aren't pre-built systems. They are what the industry calls "semi-custom configuration" machines. You pick a base line, and the adjust CPU, hard drives, memory and selected peripherals until you like it. We stick with brands and models with a good rep and that are known to work with Linux.
(Granted, after three problem units this week, I was heard to remark aloud, "We should just buy raw silicon and aluminum and build from there", but hey, everyone had their bad days...)
I am left wondering how bad is the QC over at VA that a box is allowed to leave without parts.
This industry is like that everywhere. People screw up. It is a fact of life. Better get used to it.
Where I work, within the past seven working days alone, we have received from our supplier:
- A RAID server with no RAID controller
- A rack-mount KVM with no V (no display)
We also recieved a RAID server that looked like it had been run over by a truck. Crumpled case and shattered parts. Why the shipper even thought they could pass it off as okay is beyond me...
Especially more so considering the grief this customer has already been through.
Your average company uses the same production pipeline for RMA that they do for everything else. I'm sure it was just pure bad luck that this guy got nailed this way, but the law of averages says this will happen on occasion.
What I would expect is some kind of compensation from VA (a partial refund or credit, for example) for all the trouble.
I would have some reservation about a company that does not contact a customer regarding a delay in processing...
Again, this is completely normal. Nobody admits to their delays unless you ask them about it. Is it right? No. Does it happen anyway? Yup.
... and then does not do a second inspection of all parts before delivery.
What if the error was made when the order was being keyed into the order system? That's how that RAID server I mentioned slipped through the supplier -- what they built and QC passed matched the order sheet perfectly. It just wasn't the order we faxed to them.
That's really to say nothing of the fact it took an "Ask Slashdot" story to get something done.
Of course, according to the poster claiming to be the VA Manager, the problem has been fixed and did not need an "Ask Slashdot" story to get something done.
I'm not so much defending VA here as pointing out that they seem to be operating in the same form as the rest of the industry.
The former IO.SYS and MSDOS.SYS of pre Windows 95 were changed to hide DOS.
MS Windows 95 was basically MS Windows 4.0 and MS-DOS 7.0 packaged together. DOS 7.0 was modified such that after processing CONFIG.SYS and AUTOEXEC.BAT, it automatically invoked WIN.COM. (There were other changes, but they aren't relevant to this discussion.) Once Windows was actually up and running, you saw some real changes over Win 3.x, but early on, the boot process is almost exactly the same.
The intent was to remove it then, but this broke to many programs of the time that relied on MSDOS.SYS to be there.
That is bordering on Microsoft propaganda. Some of those programs that "relied on MSDOS.SYS to be there" include COMMAND.COM and WIN.COM, I've found.
When MS was getting ready to release Windows 95, there was still a lot of hardware out there that needed real-mode DOS device drivers to work. If Microsoft got rid of DOS completely, all that hardware would be non-functional until new device drivers could be written. That was one of the biggest problems with OS/2, and Microsoft knew it. So, instead, they kept the existing system of loading Windows on top of DOS, complete with backwards compatibility with drivers loaded in CONFIG.SYS and AUTOEXEC.BAT.
(There is also a good deal of real-mode DOS activity even after Windows 4.0 is running, but for the sake of brevity, I'm ignoring that here.)
If you edit MSDOS.SYS to include the line BootGUI=0, then Windows 95 and 98 function exactly like the old DOS+Win 3.x combination did. You boot to a command prompt, and can start Windows by invoking WIN.COM.
With Me, DOS is completely removed. IO.SYS is nothing more than a loader...
This, again, borders on Microsoft propaganda. DOS isn't completely removed in WinME. Instead, the DOS kernel (such as it is) was modified to ignore CONFIG.SYS and COMMAND.COM, and instead start the Windows 4.X boot process immediately.
Rest assured that the real-mode DOS kernel is still present, functional, and quite critical in Windows Millennium.
DOS should not be loading before Windows. It shouldn't, I'm happy it's not, it's excellent that they've pulled out yet another layer of headaches, huzzah.
The problem is, they didn't pull out DOS. By all reports, WinME still uses the real-mode DOS layer to boot and for various critical system operations. Microsoft has cut back on their DOS habbit, but they haven't kicked it.
All Microsoft has done is modify the real-mode startup code to always load WIN.COM (or its moral equivalent), rather then giving you the choice between WIN.COM or COMMAND.COM like it used to.
Hardly the picture of progress some make it out to be.
The question is, did they really remove it this time, or just hide it better?
Apparently, all they have done is modified IO.SYS to always invoke WIN.COM, instead of COMMAND.COM like it used to. I'm curious as to what would happen if you replaced WIN.COM with a copy of COMMAND.COM.
All the old standbys used to test Win9X still crash WinME, from what I understand. If you fire up a DOS debugger and overwrite the first 64 KB of memory with zeros, the system will halt instantly. Why? Because Windows still depends on the real-mode DOS kernel for certain critical tasks.
Granted, WinME has not been released yet, and this is third-hand information, so take this with a good amount of salt. But extrapolating from Microsoft's past performance, I think this is a safe bet.
Could we have Anti-Windows next? Take the basic principles of Windows design (slow, clunky, bloated, crash-prone etc) and reverse them and see what happens?
Ironically enough, Microsoft is already doing some of the things talked about in the original Anti-Mac article. Iin traditional MS fashion, though, they are done not to improve the end user experience, but to lock us into their products.
For example, MS Office already "extends" the file manager in Windows to know the "attributes" of an Office file, like the author and the date of last printing. (Lock-in: Only works for Office, though.) And Win98 has the "View as Webpage" preview pane, which is a horrible implementation of a good idea. (Lock-in: You have to use IE.)
I think the point was, these things should be automatic and combine well. Manually bring up the properites of a file and changing the icon to be something else is a far, far cry from the OS automatically adding things to the existing icon to provide additional information.
Not being sarcastic, just pointing out that what you can do isn't really close to the same thing.;-)
What we want are high-level objects with implicit structure. Text files with XML structure are not good enough.
Can I ask why text files with XML structure are not good enough?
You also have to consider the issue of multiple agents. This requires a clear-cut, high-level model of interaction between systems, which, of course, doesn't exist (nor could exist) on Unix.
While I agree that such a model does not exist under Unix, can I ask why you think it cannot? I generally agree with you that a lot of the things UI-ish talked about, both generally and with this article in particular, aren't there yet on Unix, but by and large I think it is only a matter of time. I see no reason why the Unix security model in particular cannot be extended to support safe, shared control of user applications.
I think it's worth pointing out that safe, shared control in general is hard to accomplish. Almost all (working) security implementations use the principles of KISS and system high: Larger, more general security compartments tightly segregated from other systems. Consider: chroot() jails, mapping all remote access to nobody, Java, firewalls and DMZs. All of them are basically variations on the sandbox concept.
The reason is that designing and implementing a system which allows safe mixed-mode secure operation is very difficult. People make mistakes, and complexity makes mistakes harder to find and harder to prevent. The solution to this problem of limited human capability is the sandbox model. Separate systems with tightly controlled interfaces are easier to design and debug then mixed-mode, complex, interwoven systems. I don't think we'll see this changing anytime soon.
And, since I know someone is going to bring this up: No, simply stating "Use a capabilities model" is not going to solve all your problems. Capabilities (just like everything else) provide no additional security simply by existing; they have to be applied properly for them to work. Applying them properly is the crux of the matter, for there you run into all the same complexity problems you do with everything else. Capabilities are interesting and useful, but they aren't a panacea.
... the system should be developed in a high-level language itself, which could be used for remote scripting and automation as well.
I think Sun calls that Java.:-)
Although there's native support to network graphics, it's much too low-level and just generally broken.
??? Please elaborate.
Finally, as a lot of people often point out, most of the work in Free Software is still driven by imitation.
Indeed. Open Source/Free Software isn't about radical new software concepts, it is about radical new approaches to software design. (Well, actually, they're tried and true approaches to software design, but don't tell the press that.)
I don't think this is necessarily a Bad Thing. We steal from everywhere, taking what we like and leaving the rest. We then make sure what we have works, and works well. We do refine the concepts somewhat, making things more flexible and general, but we don't redesign everything. After all, you can try all the variations you want, but you always end up with a flat cylinder for the wheel.
<BASH TYPE=Gratuitous TARGET=Microsoft> I wouldn't want to take away Microsoft's Freedom to Innovate, after all.;-) </BASH>
In conclusion: unlike the author, I don't see that the GNU/Linux world is going the Anti-Mac way, quite the contrary.
I agree. And for more reasons then the ones you state. The biggest is that Unix folks are generally quite pragmatic. We stick with what works and don't try to accomplish radical new things that give us little benefit in the end. That is why we still use the same API Denis Ritchie and Ken Thompson designed. And it's why we still use X11 and the WIMP model. They work well.
Let's take a look at the so-called "Anti-Mac" interface concepts, in the context of what is being done today.
The central role of language
Basically, what this boils down to is, a voice recognition and command system with limited scope. I think we've already accomplished most of this, and I think we've realized it doesn't get you much. All you are effectively doing is using your voice instead of the mouse and keyboard. That isn't a particularly efficient way to get things done.
To truly get the benefits of the central role of language, we will need full-blown language recognition with not inconsiderate AI capabilities. Cliche as it is, the "Star Trek interface". And we're a long way off from this.
A richer internal representation of objects
Ironically enough, this is something Microsoft is pushing and doing, while Unix mostly ignores it. However, I can't help but notice that what MS has been doing seems to have the goal of tying everyone to MS Office. Not that that is a surprise.
I think it is only a matter of time before we see some sort of standard interface to application-level attributes. I mentioned this in another comment, but I think this is best done in a separate userland library, not tied to any particular filesystem or desktop environment. GNOME and KDE are both heading in this direction, but I consider that too far up the UI food-chain. This should be done at a level only slightly above the standard C library.
A more expressive interface
This is pretty much a non-issue, IMNSHO. What the authors describe in the original paper are pretty much gradual improvements and evolutions which would work equally well with traditional the WIMP UI as any other. For example, the file manager in mumble GNOME-related project mumble overlays little icons over the main icon of a file, to denote things you can do with it. Or take MS Windows. It does the same thing with the "Shortcut" icon overlay. It also has that "View as Webpage" option, which is a horrid implementation (again, designed to lock us into IE, not really make things easier) of a generally good idea: A preview pane which provides useful info about a document.
Expert users
This is another thing that would work well in a WIMP system, too. Basically, it says: Ease of use is fine, but don't make the system easy to use for the complete idiot at the cost of making it hard to use for someone with an IQ higher then 60.
It has long been observed that what the industry market-speak term "ease of use" is really several things:
Ease-of-learning: How quickly can you jump in and start using a program? Mac GUI does well here; Unix CLI does not.
Ease-of-use: Once you understand the system completely, how quickly can you get things done? The classic Mac GUI does poorly here, while the Unix CLI does very well.
Ease-of-administration: How hard is it for the people responsible for maintaining the system to keep the thing working? (This applies more to OS level stuff then application-layer code, but I mention it here for completeness.)
The "Expert users" part of "Anti-Mac" is simply the realization that one should not sacrifice ease-of-use for ease-of-learning. The old PC/GEOS environment for MS-DOS included a feature called "User Level", where you set the level of experience the user of the system had, from "Novice" to "Expert". Application programs could then adjust their presentation, hiding some features while enabling others. Unfortunately, you don't see this very often. (And, no, the "learning menus" of MS Office 2000 don't count. Everyone I know hates those things. That's not a good sign.)
Shared control
This is already being done, to a very limited extend, with things like Java and MS VBA. You let third parties provide some intelligence for your data. The problem is, of course, security. Java restores to running everything in (often poorly implemented) sandboxes, while MS VBA just ignores security completely. As previously stated, the hard part here is the complexity of mixed-mode security systems.
So, in conclusion, I don't think "Anti-Mac" is all that radical (today -- things may have been different when it was written). Most of it is already being done, to some level or another, and the rest isn't going to be feasible for some time to come. If ever.
When implemented on a traditional file system, that kind of library-based solution will always end up being inefficient and sub-optimal...
I disagree. While it is true that there will be some speed benefit to keeping metadata attributes in the same place for all files, such benefits will be insignificant for any application I can think of. Additionally, by doing things in userland, you can have multiple sources of metadata, all presented using the same interface. In other words, a file need not use the filesystem metadata to present file metadata to applications. As an example, if this is done in userland, your file manager shell could still get information about the "Artist" of a MP3, even if the program that put the MP3 into the filesystem didn't set any filesystem attributes.
... it'll feel like a dirty hack to the application programmer...
There is absolutely zero reason why this would have to be. A library call should be transparent. When you call GetFileAttributeList(ReferenceToAFile) (or whatever), you should get the exact same information regardless of where the metadata is stored. If it feels like a dirty hack, it is because of a crummy implementation.
... you'll reach a point when it's preferrable to just use a full-fledged DBMS and get it over with.
And, with proper implementation, you can still use the exact same API, even if you have gone to a full-fledged DBMS for whatever reasons. All the more reason to do it in a userland library. OTOH, if you force this into the kernel, you're stuck with what the kernel knows about.
That's why I say it doesn't belong in the kernel.
... instead of having a thousand statically-compiled (from one single big-assed C procedure) programs of a few dozen K talking to each other through a half-assed character stream system (piping? WTF?), it's better to have a million dynamic modules of a few hundred bytes, with well-defined interfaces in a high-level declarative language.
Ummmmm... kay... correct or not, what's this got to do with file attributes?:-)
Note that my +1 bonus remains turned off
Feel free. But you're using the system wrong. The point of the moderation system is not to give people a warm fuzzy that someone liked their post. It is designed to rate posts on their overall value to Slashdot readers. If you're getting a score bonus, it is because your posts are consistently moderated up, and thus your posts are considered (on the average) to be more valuable to the Slashdot readers. This automates the moderation process and lets moderators spend their points elsewhere. By using the "No Score +1 Bonus" option, you're effectively karma whoring. Not what you intended, I'm sure, but if you think about it, that is what you're doing.
The "No Score +1 Bonus" should be used if you think you're actually writing a post significantly lower in quality then what you usually write. A recreational flame, for example.
Even BeOS, which is as bad as most other OSs in the aspects discussed here, implements this concept in a limited fashion: instead of having a fixed, global, immutable set of file attributes, the Be File System associates each file type with a set of attributes.
Personally, I think this is better handled as shared user-space glue code which all applications make use of. One of the design goals of Unix (for better or worse, although it seems to work well) is to keep everything in small parts. Rather then building application file attributes into the code file system (where, really, they don't need to be), invent a libFileAttributes (or whatever) API that provides a consistant interface. Kind of like file(1), mailcap(4), and a few other things rolled into one. Indeed, such functionality might be best implemented in terms of these existing tools.
Projects like GNOME and KDE are heading in this directory, but my only real beef with such efforts is that they are generally being done at too high a level. File attributes shouldn't require a GUI to function.
Yep; in sufficiently high doses, anything can kill you. Even... water...
Yah, drop a ton of ice on someone, and they'll be dead!
;-)
Why Surge Makes You Shake
on
Caffeine Vault
·
· Score: 1
I have drank Surge and I couldn't handle after 10 sips... I can handle Dew easily.... Is there something in Surge that made me all hyped?
I think it was just the taste. No human being should be made to drink that stuff. People say Mt Dew looks like piss, but I swear I've seen pubic hair floating in Surge bottles at the store.
The problem isn't so much Perl as the syntax for regular expressions. They are designed to describe patterns of characters in as little space as possible. Perl actually helps things. For example:
# Remove any HTML tag in the submitted code # that is not in the list of okay HTML tags. $submitted_code =~ s # search for... { < # start of HTML tag (?!$okay_tags) # do NOT match $okay_tags [^>]* # any number of characters EXCEPT the HTML close > # end of HTML tag } #... and replace with nothing {} # globally, ignore case, eXtended regexps gix;
You can write bad code in any language. Perl is just about the only place you can write clear, well-commented regexps.
[Note: There may well be syntax errors in the above, as it took me forever just to get everything formatted right. (If you think Perl's bad, try translating Perl into guarded HTML!) I certainly can't run it all through the interpreter to check my translation. And I know there's at least one logic bug in the code.]
It's not Apple's call, Were Apple to open source Quicktime...
As a matter of fact, QuickTime is a reasonably open format. The xanim player for Unix, for example, does a good job with QuickTime movies for which it has codecs, and it is Open Source.
So, you're starting off with incorrect assumptions. But moving along...
It's not Apple's call... Go talk to Sorenson...
Then you said:
So you think that if Sorenson didn't have an exclusive agreement with Apple, they would just... open their code?
Okay, so people point out you are dead wrong, and suddenly your old argument disappears! It sure looks like you're just looking to cause trouble to me. Trolling for flames, are we? But, I'll give you the benefit of the doubt.
The author of xanim has contacted Sorensen about licensing the codec for implementation as a closed-source, loadable module. No source code give away, so your anti-Open Source rant is completely bull. They wouldn't even need to do the work, all they need to do is let him use the codec.
Sorensen has said they would be interested, but Apple will not let them.
So, YES, it IS Apple's restrictions that are preventing us from viewing QuickTime movies on our non-Mac, non-Windows machines. Pure and simple.
Yah, but I'd still rather have the choice. Apple says "Thou Shalt Have This Case, And Thou Shalt Like It". With choice comes the inevitable sucky products, but it also brings a larger number of good products.
... while no more than 5-10% of PC's sold have anything that is close to acceptable.
Sure, 90% of PC cases are crap. 90% of everything is crap. Sturgeon's Law.
Have you ever tried to quickly swap cards, RAM or drives in a regular ol' PC tower case? it sucks. The Blue+White G3 and G4 cases rock hard when in comes to this sort of thing.
It depends entirely on the case. With some of the new Dell cases I've been working on for a client, or the generic CasEdge PC cases we by ourselves, you simply push a button, pop the side and front panels, and pull the drives out on a rails. Even the rails are screwless; they use spring clips.
Sure, you can find a lot more sucky PC cases then you can find sucky Mac cases, but you'll find a lot more PC cases period, too. When you only have one supplier, quality control better be good, or you'll soon have zero suppliers.
From a gamer's point of view, Linux has POS networking because it won't work on his modem and/or his ISP.
Ya know, be-fan, you've gone downhill. You at least used to bring some interesting discussion and some useful sanity checks to the Linux lovefests we usually get around here.
Modems
Like a gammer who is really concerned about performance is going to use a sucky, crappy, fart eating, slug loving software-driven winmodem! They suck! Even on Windows machines with the latest hardware and software, they suck! When I upgrade a Windows machine with a Winmodem in it, the first thing I do is rip it out and bash it up with a hammer, and then burn it.
ISPs
Your average ISP works very well with Linux, than you very much. Often better, in fact. Sometimes Linux is even optimized, because the ISP is often running Linux, too.
True, some of your "free" ISPs don't work well with Linux, but a hardcore gammer isn't going to be using a sucky free ISP with a bogged pipe and ad software to steal bandwidth and CPU cycles, is he?
A friend of mine just got a DSL connection. Their game performance actually increased when we put them behind a Linux firewall on an old Pentium! That's how kooky Windows's IP stack is!
Me? no, but other people have, but they're too new to matter. (IPX comes to mind.)
IPX?? Novell's IPX?? The so-called Internetwork Packet Exchange? Oh please.
IPX is crufty, badly designed, overly dependent on broadcast traffic, highly propriatary, hard to route, not subnetable, and basically sucks. And if you think TCP has high overhead, try Novell STREAMS layered on top of SPX layered on top of IPX controlled by broadcast SAP. Even Novell admits IPX is crap, and has moved to pure IP with NetWare V5.
Again: Go back to flaming people who think Linux beats BeOS for multimedia performance. You're out of your league here.
Normally, I'd just ignore a troll like you, but what the hell. I'm bored and haven't flamed anyone in a while.
True. IP is a terrible protocol. It has a lot of overhead, plus it has a lot of connection startup time.
Too bad IP doesn't have connections. It's a stateless, unreliable, unsequenced datagram protocol. I'll cut you some slack -- maybe you meant TCP? Well, true, it does have some overhead, but that's the price you pay for building a reliable data stream protocol on top of an unreliable, packeted-based protocol. I'd like to see you do a better job.
Who decided to use TCP/IP for internet anyway?
The US Department of Defense.
If you're also wondering why, it's because IP does a damn good job given the constraints it has and had to work with. Again, I'd like to see you do a better job.
HTTP is also pretty limited. Read the/. article on what they're trying to replace it with.
You mean BXXP? Which is basically TCP layered on top of TCP? And you're complaining about the overhead of TCP? Um, hello, McFly? Anyone home?
Let's see... never mind, I couldn't care less what protocol my email system uses.
If you really don't care about all this stuff, why the hell are you posting about it? This is the thing that really gives you away as a troll. Never, ever admit you're not interested in the subject matter, or the whole gig is up.
X11 doesn't have more stability than Aqua.
X11 has been around for how many years? Meanwhile, this is the third or fourth major iteration of the Macintosh graphics interface? Riiight.
However, it is a lot faster and more powerful.
I don't really expect Aqua to be much faster then X11. Perhaps slightly so, simply because it is more limited. But not significantly so.
As far as power goes, you're dead wrong. Extensibility, network transparency, host, machine, and transport independence are just a few of the things X11 has that Mac OS X's graphics system doesn't.
Interoperability seems to be the only thing left, and 99% of Mac users couldn't care less about that.
Absolute balderdash. Ask any Mac user, and the number one thing they hate is the fact that the rest of the world assumes you're running MS Windows on an Intel-based system.
I don't own an IBM mainframe or a Palm Pilot.
No shit? Like that makes a whole hell of a lot of difference to my argument. The point was, X11 will go with you no matter where you go, not that you could run it on the IBM S/390 you have in your bedroom.
And even if they did, the PP doesn't have an X server.
I've seen one for it, so you're wrong yet again.
You have to take this in contex. He is talking about X11 within the context of a desktop OS. In that context, X11 is worse than the Win9x GDI.
Actually, the OP and you are both talking out of your ass, because Aqua is really the UI layer, not the graphics layer like X11 is. It's comparing apples to oranges. The point I was trying to make was that standards are a good thing, which you've missed entirely. Instead, and as usual, you've tried to divert the discussion to a flamewar of Unix vs this mythical "desktop OS" you always bring up.
But, let's indulge you. X11 vs Win9X GDI. At least you got the layers right for that one. The GDI is encumbered with backwards compatability with years worth of things that don't exist anymore. It's tied to Windows. It's tied to the Intel platform. The API changes with each major release of the OS. It's poorly and often incorrectly documented. It's propriatary. It's a pain in the ass to work with. It's limited to a single user on a single machine. In short, it's crap.
be-fan, you know BeOS, and you make some good points about its advantages, but you're out of your league here. Stick to what you know.
Want a fun, quirky car with room for four? Get a New Beetle.
You mean, "Want a fun, quirky car that costs nearly twice as much as the same car without the funky styling? Get a New Beetle."
Don't get my wrong, VM makes fine cars, and the New Beetle does look kind of cool, but it isn't worth the price premium. They cost as much as a small SUV!
The main reason that people run X is not because it is great or beautiful or a wonderful piece of engineering... It is because it is the only real standard for accessing bitmapped displays under UNIX/Linux.
And the main reason that people run IP is that it is the only real standard for accessing network resources under Unix.
And the main reason people use HTTP for web browsing is that it is the only real standard for transporting hypertext.
And the main reason people use SMTP, POP, and/or IMAP is -- you guessed it -- they are the standards for accessing email.
You say "standard" like it is a bad thing. Believe it or not, there are those of us who prefer interoperability and stability over flashy looks.
Aqua may be cool and all, but will it run on any computer from an IBM mainframe to a Palm Pilot? No, I didn't think so. But X11 will. This doesn't make Aqua inferior or X11 better, but it is a distinction to be aware of.
For those who whine about not getting posted
on
MacOSX and X11
·
· Score: 2
Really, this is the answer for all those people who whine about, "Hey, no fair, I submitted my story 0.03849 seconds before ThisOtherGuy did, and yet they posted his instead! It's a conspiracy, I tell ya!"
Didn't get your submit posted? No problem. All you have to do is date the owner.;-)
In this case, releasing the source to the driver would not do the company any harm that wasn't already in the works.
Exactly! Someone give StormReaver a beverage of his or her choice.
If your company is depending solely on the fact that their software is only distributed as object code to ensure their continued livelihood, then I recommend that you start looking for employment elsewhere. Because in short order, someone is going to disassemble the object code and use it to ruin you.
In the end, both source and object code are exactly the same thing: Instructions to the computer. The form they take makes things slightly more difficult, but no more so then keeping all your trade secrets in French does.
Likewise, if you're depending on IP law to protect you (copyrights, patents, trademarks, etc.), they will continue to do so even if you do release the source.
Closed source as security is security through obscurity, which doesn't work, regardless if you are protecting data files on your server or the source itself.
Slashdot Mirror
I basically agree with you. But:
All any company like VA does is take off-the-shelf OEM parts, slap a machine together, and glue a little plastic logo on the front of the case.
While there are many companies like that, VA is not one of them.
They know Linux, what it needs, and what it does. They specialize in Linux and Linux compatibility. This is more then I can say for Dell, Compaq, or HP at this point.
VA does a good deal of research and testing to make sure their stuff is Linux compatible.
VA provides Linux-specific documentation.
They do a fair amount of custom engineering when needed, especially in their low-profile rack-mount servers.
They give back to the Linux community quite a bit.
Now, none of this excuses poor customer service or quality, but your claim that VA is just another Intel PC VAR isn't true.
Youre not getting anything you couldn't otherwise assemble on your own, or obtain from a larger LInux systems vendor such as IBM, Dell, and others.
I think not.
HP: Other then in press releases, their hardware literature doesn't mention Linux, and you can't configure a system with Linux pre-installed on it. Doesn't look too promising to me.
Compaq: LOL. Their "Linux" page wants to sell you machines with Windows pre-installed. Give me a break.
IBM: I haven't dealt with IBM on Linux, but I have gotten the impression that, while serious about Linux, they are still ramping up to really support it well on their Intel lines. But at least they'll sell you a system with Linux on it.
Dell: Will sell you a system with Linux, and at least seems to be committed to it. But, they really have a ways to go. They will happilly bundle NT software with your Linux system, and wonder why you say you cannot use it. And their Linux driver support is iffy.
Would I buy a VA Linux system? Unlikely. Are they doing as good a job as they should? Maybe not. Are they as bad as you make them out to be? No.
Why are people buying prebuild crap from companies that treat them like crap?
Well, I don't know about anybody else, but I can talk about the company I work for.
We're a small-time integrator specializing in Linux. Even being small, we ship between two and ten servers a month. It is easier for us to pay someone else to build them for us then it is for us to build them ourselves.
And these aren't pre-built systems. They are what the industry calls "semi-custom configuration" machines. You pick a base line, and the adjust CPU, hard drives, memory and selected peripherals until you like it. We stick with brands and models with a good rep and that are known to work with Linux.
(Granted, after three problem units this week, I was heard to remark aloud, "We should just buy raw silicon and aluminum and build from there", but hey, everyone had their bad days...)
Just FYI.
I am left wondering how bad is the QC over at VA that a box is allowed to leave without parts.
...
... and then does not do a second inspection of all parts before delivery.
This industry is like that everywhere. People screw up. It is a fact of life. Better get used to it.
Where I work, within the past seven working days alone, we have received from our supplier:
- A RAID server with no RAID controller
- A rack-mount KVM with no V (no display)
We also recieved a RAID server that looked like it had been run over by a truck. Crumpled case and shattered parts. Why the shipper even thought they could pass it off as okay is beyond me...
Especially more so considering the grief this customer has already been through.
Your average company uses the same production pipeline for RMA that they do for everything else. I'm sure it was just pure bad luck that this guy got nailed this way, but the law of averages says this will happen on occasion.
What I would expect is some kind of compensation from VA (a partial refund or credit, for example) for all the trouble.
I would have some reservation about a company that does not contact a customer regarding a delay in processing
Again, this is completely normal. Nobody admits to their delays unless you ask them about it. Is it right? No. Does it happen anyway? Yup.
What if the error was made when the order was being keyed into the order system? That's how that RAID server I mentioned slipped through the supplier -- what they built and QC passed matched the order sheet perfectly. It just wasn't the order we faxed to them.
That's really to say nothing of the fact it took an "Ask Slashdot" story to get something done.
Of course, according to the poster claiming to be the VA Manager, the problem has been fixed and did not need an "Ask Slashdot" story to get something done.
I'm not so much defending VA here as pointing out that they seem to be operating in the same form as the rest of the industry.
The former IO.SYS and MSDOS.SYS of pre Windows 95 were changed to hide DOS.
...
MS Windows 95 was basically MS Windows 4.0 and MS-DOS 7.0 packaged together. DOS 7.0 was modified such that after processing CONFIG.SYS and AUTOEXEC.BAT, it automatically invoked WIN.COM. (There were other changes, but they aren't relevant to this discussion.) Once Windows was actually up and running, you saw some real changes over Win 3.x, but early on, the boot process is almost exactly the same.
The intent was to remove it then, but this broke to many programs of the time that relied on MSDOS.SYS to be there.
That is bordering on Microsoft propaganda. Some of those programs that "relied on MSDOS.SYS to be there" include COMMAND.COM and WIN.COM, I've found.
When MS was getting ready to release Windows 95, there was still a lot of hardware out there that needed real-mode DOS device drivers to work. If Microsoft got rid of DOS completely, all that hardware would be non-functional until new device drivers could be written. That was one of the biggest problems with OS/2, and Microsoft knew it. So, instead, they kept the existing system of loading Windows on top of DOS, complete with backwards compatibility with drivers loaded in CONFIG.SYS and AUTOEXEC.BAT.
(There is also a good deal of real-mode DOS activity even after Windows 4.0 is running, but for the sake of brevity, I'm ignoring that here.)
If you edit MSDOS.SYS to include the line BootGUI=0, then Windows 95 and 98 function exactly like the old DOS+Win 3.x combination did. You boot to a command prompt, and can start Windows by invoking WIN.COM.
With Me, DOS is completely removed. IO.SYS is nothing more than a loader
This, again, borders on Microsoft propaganda. DOS isn't completely removed in WinME. Instead, the DOS kernel (such as it is) was modified to ignore CONFIG.SYS and COMMAND.COM, and instead start the Windows 4.X boot process immediately.
Rest assured that the real-mode DOS kernel is still present, functional, and quite critical in Windows Millennium.
DOS should not be loading before Windows. It shouldn't, I'm happy it's not, it's excellent that they've pulled out yet another layer of headaches, huzzah.
The problem is, they didn't pull out DOS. By all reports, WinME still uses the real-mode DOS layer to boot and for various critical system operations. Microsoft has cut back on their DOS habbit, but they haven't kicked it.
All Microsoft has done is modify the real-mode startup code to always load WIN.COM (or its moral equivalent), rather then giving you the choice between WIN.COM or COMMAND.COM like it used to.
Hardly the picture of progress some make it out to be.
The question is, did they really remove it this time, or just hide it better?
Apparently, all they have done is modified IO.SYS to always invoke WIN.COM, instead of COMMAND.COM like it used to. I'm curious as to what would happen if you replaced WIN.COM with a copy of COMMAND.COM.
All the old standbys used to test Win9X still crash WinME, from what I understand. If you fire up a DOS debugger and overwrite the first 64 KB of memory with zeros, the system will halt instantly. Why? Because Windows still depends on the real-mode DOS kernel for certain critical tasks.
Granted, WinME has not been released yet, and this is third-hand information, so take this with a good amount of salt. But extrapolating from Microsoft's past performance, I think this is a safe bet.
Could we have Anti-Windows next? Take the basic principles of Windows design (slow, clunky, bloated, crash-prone etc) and reverse them and see what happens?
Ironically enough, Microsoft is already doing some of the things talked about in the original Anti-Mac article. Iin traditional MS fashion, though, they are done not to improve the end user experience, but to lock us into their products.
For example, MS Office already "extends" the file manager in Windows to know the "attributes" of an Office file, like the author and the date of last printing. (Lock-in: Only works for Office, though.) And Win98 has the "View as Webpage" preview pane, which is a horrible implementation of a good idea. (Lock-in: You have to use IE.)
Already in the Mac altho manual or scripted...
;-)
I think the point was, these things should be automatic and combine well. Manually bring up the properites of a file and changing the icon to be something else is a far, far cry from the OS automatically adding things to the existing icon to provide additional information.
Not being sarcastic, just pointing out that what you can do isn't really close to the same thing.
What we want are high-level objects with implicit structure. Text files with XML structure are not good enough.
... the system should be developed in a high-level language itself, which could be used for remote scripting and automation as well.
:-)
;-) </BASH>
Can I ask why text files with XML structure are not good enough?
You also have to consider the issue of multiple agents. This requires a clear-cut, high-level model of interaction between systems, which, of course, doesn't exist (nor could exist) on Unix.
While I agree that such a model does not exist under Unix, can I ask why you think it cannot? I generally agree with you that a lot of the things UI-ish talked about, both generally and with this article in particular, aren't there yet on Unix, but by and large I think it is only a matter of time. I see no reason why the Unix security model in particular cannot be extended to support safe, shared control of user applications.
I think it's worth pointing out that safe, shared control in general is hard to accomplish. Almost all (working) security implementations use the principles of KISS and system high: Larger, more general security compartments tightly segregated from other systems. Consider: chroot() jails, mapping all remote access to nobody, Java, firewalls and DMZs. All of them are basically variations on the sandbox concept.
The reason is that designing and implementing a system which allows safe mixed-mode secure operation is very difficult. People make mistakes, and complexity makes mistakes harder to find and harder to prevent. The solution to this problem of limited human capability is the sandbox model. Separate systems with tightly controlled interfaces are easier to design and debug then mixed-mode, complex, interwoven systems. I don't think we'll see this changing anytime soon.
And, since I know someone is going to bring this up: No, simply stating "Use a capabilities model" is not going to solve all your problems. Capabilities (just like everything else) provide no additional security simply by existing; they have to be applied properly for them to work. Applying them properly is the crux of the matter, for there you run into all the same complexity problems you do with everything else. Capabilities are interesting and useful, but they aren't a panacea.
I think Sun calls that Java.
Although there's native support to network graphics, it's much too low-level and just generally broken.
??? Please elaborate.
Finally, as a lot of people often point out, most of the work in Free Software is still driven by imitation.
Indeed. Open Source/Free Software isn't about radical new software concepts, it is about radical new approaches to software design. (Well, actually, they're tried and true approaches to software design, but don't tell the press that.)
I don't think this is necessarily a Bad Thing. We steal from everywhere, taking what we like and leaving the rest. We then make sure what we have works, and works well. We do refine the concepts somewhat, making things more flexible and general, but we don't redesign everything. After all, you can try all the variations you want, but you always end up with a flat cylinder for the wheel.
<BASH TYPE=Gratuitous TARGET=Microsoft> I wouldn't want to take away Microsoft's Freedom to Innovate, after all.
In conclusion: unlike the author, I don't see that the GNU/Linux world is going the Anti-Mac way, quite the contrary.
I agree. And for more reasons then the ones you state. The biggest is that Unix folks are generally quite pragmatic. We stick with what works and don't try to accomplish radical new things that give us little benefit in the end. That is why we still use the same API Denis Ritchie and Ken Thompson designed. And it's why we still use X11 and the WIMP model. They work well.
Let's take a look at the so-called "Anti-Mac" interface concepts, in the context of what is being done today.
The central role of language
Basically, what this boils down to is, a voice recognition and command system with limited scope. I think we've already accomplished most of this, and I think we've realized it doesn't get you much. All you are effectively doing is using your voice instead of the mouse and keyboard. That isn't a particularly efficient way to get things done.
To truly get the benefits of the central role of language, we will need full-blown language recognition with not inconsiderate AI capabilities. Cliche as it is, the "Star Trek interface". And we're a long way off from this.
A richer internal representation of objects
Ironically enough, this is something Microsoft is pushing and doing, while Unix mostly ignores it. However, I can't help but notice that what MS has been doing seems to have the goal of tying everyone to MS Office. Not that that is a surprise.
I think it is only a matter of time before we see some sort of standard interface to application-level attributes. I mentioned this in another comment, but I think this is best done in a separate userland library, not tied to any particular filesystem or desktop environment. GNOME and KDE are both heading in this direction, but I consider that too far up the UI food-chain. This should be done at a level only slightly above the standard C library.
A more expressive interface
This is pretty much a non-issue, IMNSHO. What the authors describe in the original paper are pretty much gradual improvements and evolutions which would work equally well with traditional the WIMP UI as any other. For example, the file manager in mumble GNOME-related project mumble overlays little icons over the main icon of a file, to denote things you can do with it. Or take MS Windows. It does the same thing with the "Shortcut" icon overlay. It also has that "View as Webpage" option, which is a horrid implementation (again, designed to lock us into IE, not really make things easier) of a generally good idea: A preview pane which provides useful info about a document.
Expert users
This is another thing that would work well in a WIMP system, too. Basically, it says: Ease of use is fine, but don't make the system easy to use for the complete idiot at the cost of making it hard to use for someone with an IQ higher then 60.
It has long been observed that what the industry market-speak term "ease of use" is really several things:
Ease-of-learning: How quickly can you jump in and start using a program? Mac GUI does well here; Unix CLI does not.
Ease-of-use: Once you understand the system completely, how quickly can you get things done? The classic Mac GUI does poorly here, while the Unix CLI does very well.
Ease-of-administration: How hard is it for the people responsible for maintaining the system to keep the thing working? (This applies more to OS level stuff then application-layer code, but I mention it here for completeness.)
The "Expert users" part of "Anti-Mac" is simply the realization that one should not sacrifice ease-of-use for ease-of-learning. The old PC/GEOS environment for MS-DOS included a feature called "User Level", where you set the level of experience the user of the system had, from "Novice" to "Expert". Application programs could then adjust their presentation, hiding some features while enabling others. Unfortunately, you don't see this very often. (And, no, the "learning menus" of MS Office 2000 don't count. Everyone I know hates those things. That's not a good sign.)
Shared control
This is already being done, to a very limited extend, with things like Java and MS VBA. You let third parties provide some intelligence for your data. The problem is, of course, security. Java restores to running everything in (often poorly implemented) sandboxes, while MS VBA just ignores security completely. As previously stated, the hard part here is the complexity of mixed-mode security systems.
So, in conclusion, I don't think "Anti-Mac" is all that radical (today -- things may have been different when it was written). Most of it is already being done, to some level or another, and the rest isn't going to be feasible for some time to come. If ever.
When implemented on a traditional file system, that kind of library-based solution will always end up being inefficient and sub-optimal ...
... it'll feel like a dirty hack to the application programmer ...
... you'll reach a point when it's preferrable to just use a full-fledged DBMS and get it over with.
... instead of having a thousand statically-compiled (from one single big-assed C procedure) programs of a few dozen K talking to each other through a half-assed character stream system (piping? WTF?), it's better to have a million dynamic modules of a few hundred bytes, with well-defined interfaces in a high-level declarative language.
:-)
I disagree. While it is true that there will be some speed benefit to keeping metadata attributes in the same place for all files, such benefits will be insignificant for any application I can think of. Additionally, by doing things in userland, you can have multiple sources of metadata, all presented using the same interface. In other words, a file need not use the filesystem metadata to present file metadata to applications. As an example, if this is done in userland, your file manager shell could still get information about the "Artist" of a MP3, even if the program that put the MP3 into the filesystem didn't set any filesystem attributes.
There is absolutely zero reason why this would have to be. A library call should be transparent. When you call GetFileAttributeList(ReferenceToAFile) (or whatever), you should get the exact same information regardless of where the metadata is stored. If it feels like a dirty hack, it is because of a crummy implementation.
And, with proper implementation, you can still use the exact same API, even if you have gone to a full-fledged DBMS for whatever reasons. All the more reason to do it in a userland library. OTOH, if you force this into the kernel, you're stuck with what the kernel knows about.
That's why I say it doesn't belong in the kernel.
Ummmmm... kay... correct or not, what's this got to do with file attributes?
Note that my +1 bonus remains turned off
Feel free. But you're using the system wrong. The point of the moderation system is not to give people a warm fuzzy that someone liked their post. It is designed to rate posts on their overall value to Slashdot readers. If you're getting a score bonus, it is because your posts are consistently moderated up, and thus your posts are considered (on the average) to be more valuable to the Slashdot readers. This automates the moderation process and lets moderators spend their points elsewhere. By using the "No Score +1 Bonus" option, you're effectively karma whoring. Not what you intended, I'm sure, but if you think about it, that is what you're doing.
The "No Score +1 Bonus" should be used if you think you're actually writing a post significantly lower in quality then what you usually write. A recreational flame, for example.
Even BeOS, which is as bad as most other OSs in the aspects discussed here, implements this concept in a limited fashion: instead of having a fixed, global, immutable set of file attributes, the Be File System associates each file type with a set of attributes.
Personally, I think this is better handled as shared user-space glue code which all applications make use of. One of the design goals of Unix (for better or worse, although it seems to work well) is to keep everything in small parts. Rather then building application file attributes into the code file system (where, really, they don't need to be), invent a libFileAttributes (or whatever) API that provides a consistant interface. Kind of like file(1), mailcap(4), and a few other things rolled into one. Indeed, such functionality might be best implemented in terms of these existing tools.
Projects like GNOME and KDE are heading in this directory, but my only real beef with such efforts is that they are generally being done at too high a level. File attributes shouldn't require a GUI to function.
Yep; in sufficiently high doses, anything can kill you. Even ... water ...
Yah, drop a ton of ice on someone, and they'll be dead!
;-)
I have drank Surge and I couldn't handle after 10 sips ... I can handle Dew easily. ... Is there something in Surge that made me all hyped?
I think it was just the taste. No human being should be made to drink that stuff. People say Mt Dew looks like piss, but I swear I've seen pubic hair floating in Surge bottles at the store.
Your example of some Perl code:
... ... and replace with nothing
s#<(?!$okay_tags)([^>]*>)##gi;
The problem isn't so much Perl as the syntax for regular expressions. They are designed to describe patterns of characters in as little space as possible. Perl actually helps things. For example:
# Remove any HTML tag in the submitted code
# that is not in the list of okay HTML tags.
$submitted_code =~ s
# search for
{
< # start of HTML tag
(?!$okay_tags) # do NOT match $okay_tags
[^>]* # any number of characters EXCEPT the HTML close
> # end of HTML tag
}
#
{}
# globally, ignore case, eXtended regexps
gix;
You can write bad code in any language. Perl is just about the only place you can write clear, well-commented regexps.
[Note: There may well be syntax errors in the above, as it took me forever just to get everything formatted right. (If you think Perl's bad, try translating Perl into guarded HTML!) I certainly can't run it all through the interpreter to check my translation. And I know there's at least one logic bug in the code.]
It's not Apple's call, Were Apple to open source Quicktime ...
... Go talk to Sorenson ...
... open their code?
As a matter of fact, QuickTime is a reasonably open format. The xanim player for Unix, for example, does a good job with QuickTime movies for which it has codecs, and it is Open Source.
So, you're starting off with incorrect assumptions. But moving along...
It's not Apple's call
Then you said:
So you think that if Sorenson didn't have an exclusive agreement with Apple, they would just
Okay, so people point out you are dead wrong, and suddenly your old argument disappears! It sure looks like you're just looking to cause trouble to me. Trolling for flames, are we? But, I'll give you the benefit of the doubt.
The author of xanim has contacted Sorensen about licensing the codec for implementation as a closed-source, loadable module. No source code give away, so your anti-Open Source rant is completely bull. They wouldn't even need to do the work, all they need to do is let him use the codec.
Sorensen has said they would be interested, but Apple will not let them.
So, YES, it IS Apple's restrictions that are preventing us from viewing QuickTime movies on our non-Mac, non-Windows machines. Pure and simple.
Get a clue.
It's easy to find a good Mac case ...
... while no more than 5-10% of PC's sold have anything that is close to acceptable.
Yah, but I'd still rather have the choice. Apple says "Thou Shalt Have This Case, And Thou Shalt Like It". With choice comes the inevitable sucky products, but it also brings a larger number of good products.
Sure, 90% of PC cases are crap. 90% of everything is crap. Sturgeon's Law.
FYI, CasEdge is at http://www.casedge.com, and the particular model that sits on my desktop is the LX734A.
And I bet the name "Adolf Hitler" is recognizable by a huge number of people, too. But I'm not about to name my kid after him.
Have you ever tried to quickly swap cards, RAM or drives in a regular ol' PC tower case? it sucks. The Blue+White G3 and G4 cases rock hard when in comes to this sort of thing.
It depends entirely on the case. With some of the new Dell cases I've been working on for a client, or the generic CasEdge PC cases we by ourselves, you simply push a button, pop the side and front panels, and pull the drives out on a rails. Even the rails are screwless; they use spring clips.
Sure, you can find a lot more sucky PC cases then you can find sucky Mac cases, but you'll find a lot more PC cases period, too. When you only have one supplier, quality control better be good, or you'll soon have zero suppliers.
From a gamer's point of view, Linux has POS networking because it won't work on his modem and/or his ISP.
Ya know, be-fan, you've gone downhill. You at least used to bring some interesting discussion and some useful sanity checks to the Linux lovefests we usually get around here.
Modems
Like a gammer who is really concerned about performance is going to use a sucky, crappy, fart eating, slug loving software-driven winmodem! They suck! Even on Windows machines with the latest hardware and software, they suck! When I upgrade a Windows machine with a Winmodem in it, the first thing I do is rip it out and bash it up with a hammer, and then burn it.
ISPs
Your average ISP works very well with Linux, than you very much. Often better, in fact. Sometimes Linux is even optimized, because the ISP is often running Linux, too.
True, some of your "free" ISPs don't work well with Linux, but a hardcore gammer isn't going to be using a sucky free ISP with a bogged pipe and ad software to steal bandwidth and CPU cycles, is he?
A friend of mine just got a DSL connection. Their game performance actually increased when we put them behind a Linux firewall on an old Pentium! That's how kooky Windows's IP stack is!
Me? no, but other people have, but they're too new to matter. (IPX comes to mind.)
IPX?? Novell's IPX?? The so-called Internetwork Packet Exchange? Oh please.
IPX is crufty, badly designed, overly dependent on broadcast traffic, highly propriatary, hard to route, not subnetable, and basically sucks. And if you think TCP has high overhead, try Novell STREAMS layered on top of SPX layered on top of IPX controlled by broadcast SAP. Even Novell admits IPX is crap, and has moved to pure IP with NetWare V5.
Again: Go back to flaming people who think Linux beats BeOS for multimedia performance. You're out of your league here.
Normally, I'd just ignore a troll like you, but what the hell. I'm bored and haven't flamed anyone in a while.
/. article on what they're trying to replace it with.
True. IP is a terrible protocol. It has a lot of overhead, plus it has a lot of connection startup time.
Too bad IP doesn't have connections. It's a stateless, unreliable, unsequenced datagram protocol. I'll cut you some slack -- maybe you meant TCP? Well, true, it does have some overhead, but that's the price you pay for building a reliable data stream protocol on top of an unreliable, packeted-based protocol. I'd like to see you do a better job.
Who decided to use TCP/IP for internet anyway?
The US Department of Defense.
If you're also wondering why, it's because IP does a damn good job given the constraints it has and had to work with. Again, I'd like to see you do a better job.
HTTP is also pretty limited. Read the
You mean BXXP? Which is basically TCP layered on top of TCP? And you're complaining about the overhead of TCP? Um, hello, McFly? Anyone home?
Let's see... never mind, I couldn't care less what protocol my email system uses.
If you really don't care about all this stuff, why the hell are you posting about it? This is the thing that really gives you away as a troll. Never, ever admit you're not interested in the subject matter, or the whole gig is up.
X11 doesn't have more stability than Aqua.
X11 has been around for how many years? Meanwhile, this is the third or fourth major iteration of the Macintosh graphics interface? Riiight.
However, it is a lot faster and more powerful.
I don't really expect Aqua to be much faster then X11. Perhaps slightly so, simply because it is more limited. But not significantly so.
As far as power goes, you're dead wrong. Extensibility, network transparency, host, machine, and transport independence are just a few of the things X11 has that Mac OS X's graphics system doesn't.
Interoperability seems to be the only thing left, and 99% of Mac users couldn't care less about that.
Absolute balderdash. Ask any Mac user, and the number one thing they hate is the fact that the rest of the world assumes you're running MS Windows on an Intel-based system.
I don't own an IBM mainframe or a Palm Pilot.
No shit? Like that makes a whole hell of a lot of difference to my argument. The point was, X11 will go with you no matter where you go, not that you could run it on the IBM S/390 you have in your bedroom.
And even if they did, the PP doesn't have an X server.
I've seen one for it, so you're wrong yet again.
You have to take this in contex. He is talking about X11 within the context of a desktop OS. In that context, X11 is worse than the Win9x GDI.
Actually, the OP and you are both talking out of your ass, because Aqua is really the UI layer, not the graphics layer like X11 is. It's comparing apples to oranges. The point I was trying to make was that standards are a good thing, which you've missed entirely. Instead, and as usual, you've tried to divert the discussion to a flamewar of Unix vs this mythical "desktop OS" you always bring up.
But, let's indulge you. X11 vs Win9X GDI. At least you got the layers right for that one. The GDI is encumbered with backwards compatability with years worth of things that don't exist anymore. It's tied to Windows. It's tied to the Intel platform. The API changes with each major release of the OS. It's poorly and often incorrectly documented. It's propriatary. It's a pain in the ass to work with. It's limited to a single user on a single machine. In short, it's crap.
be-fan, you know BeOS, and you make some good points about its advantages, but you're out of your league here. Stick to what you know.
Want a fun, quirky car with room for four? Get a New Beetle.
You mean, "Want a fun, quirky car that costs nearly twice as much as the same car without the funky styling? Get a New Beetle."
Don't get my wrong, VM makes fine cars, and the New Beetle does look kind of cool, but it isn't worth the price premium. They cost as much as a small SUV!
The main reason that people run X is not because it is great or beautiful or a wonderful piece of engineering ... It is because it is the only real standard for accessing bitmapped displays under UNIX/Linux.
And the main reason that people run IP is that it is the only real standard for accessing network resources under Unix.
And the main reason people use HTTP for web browsing is that it is the only real standard for transporting hypertext.
And the main reason people use SMTP, POP, and/or IMAP is -- you guessed it -- they are the standards for accessing email.
You say "standard" like it is a bad thing. Believe it or not, there are those of us who prefer interoperability and stability over flashy looks.
Aqua may be cool and all, but will it run on any computer from an IBM mainframe to a Palm Pilot? No, I didn't think so. But X11 will. This doesn't make Aqua inferior or X11 better, but it is a distinction to be aware of.
Really, this is the answer for all those people who whine about, "Hey, no fair, I submitted my story 0.03849 seconds before ThisOtherGuy did, and yet they posted his instead! It's a conspiracy, I tell ya!"
;-)
Didn't get your submit posted? No problem. All you have to do is date the owner.
In this case, releasing the source to the driver would not do the company any harm that wasn't already in the works.
Exactly! Someone give StormReaver a beverage of his or her choice.
If your company is depending solely on the fact that their software is only distributed as object code to ensure their continued livelihood, then I recommend that you start looking for employment elsewhere. Because in short order, someone is going to disassemble the object code and use it to ruin you.
In the end, both source and object code are exactly the same thing: Instructions to the computer. The form they take makes things slightly more difficult, but no more so then keeping all your trade secrets in French does.
Likewise, if you're depending on IP law to protect you (copyrights, patents, trademarks, etc.), they will continue to do so even if you do release the source.
Closed source as security is security through obscurity, which doesn't work, regardless if you are protecting data files on your server or the source itself.