Me:You see, there are no mystery processes under Linux. There are no huge, monolithic programs that are part of the system. No single, huge "System Services Manager".
You:In fact, my friend, that is exactly what the Linux kernel is. Yes, the Linux kernel is a huge, monolithic program (thus the term "monolithic kernel") that contains a good deal of Linux's device support as well as a zillion other things.
Not quite the same thing.
Yes, the kernel is a monolithic kernel. That refers to the design of the memory management and scheduling of the kernel. All parts of the kernel share the same memory space and are scheduled together. This is one of the reasons Linux performs so well -- the kernel isn't preemptable, so there is no overhead of task switching in the kernel.
However, the kernel is still nicely modularized into separate components for software maintence, and compiles to a small binary that performs one task -- low-level device abstraction -- well. True, all of your low-level device abstraction is happening in the same program, but there really isn't a way around that. Device drivers have to have kernel privileges.
Comparing that to what I was referring to -- the many "monolithic" userland programs in Windows -- is an error. I was referring to the fact that there are a great many "do it all" processes in Windows which are essentially opaque, such as SVCHOST.EXE. You have no idea what they really do. You cannot get inside them to diagnose problems. They are a magic black box, which you are forced to trust. Hence the term "monolithic". Sorry if my usage confused you.
Now, there are various projects to include userland functionality -- knfsd, for NFS service, and khttpd, for web service -- in the Linux kernel, but I consider them the wrong solution to a problem. Fortunately, I don't have to include them in my kernel -- I can easily exclude them at compile-time, or not load them if I'm using pre-compiled modules.
That is another thing you cannot do with Windows -- you have to accept Microsoft's choices for what is and is not in the kernel. Such as the graphics layer. Originally, NT 3.x did not include the graphics subsystem in the NT kernel. This is one of the reasons NT 3.x was so slow, but it did mean better stability. However, MS decided to move parts of the GUI into the kernel itself with NT 4. This made things faster, but means there is a lot more that can go wrong in the critical kernel code.
Hmm. I guess you didn't read my article too well. I didn't use backup software to back up my files.
Hmmm. I guess you didn't write your article too well. I quote, "...installed Win2K, did an emergency restore of my wonko.com backup (which, luckily, was totally up to date)." Sure sounds like a Win2K backup program to me! How was I supposed to know that a totally up-to-date "backup" really meant you did a file copy after the problem happened? To me, a backup is something you do before problems occur.
(And before you start jumping up and down about your usage of "DOS" in the next sentence, realize that: MS still uses DOS today in some of its products. MS supports DOS programs under NT. MS has system recovery procedures that work with NT using DOS. Using a DOS-based program to run a system restore program is something they've done in the past. I didn't know you meant the actual MS-DOS(TM) product running instead of NT. I didn't think anybody still used stand-alone DOS.)
When I made that statement, I was referring to the final release of Windows 2000, which I am now using. My previous problems, as I've stated before, were with a beta version of the OS.
That is very true, but I believe the problems I describe are flaws in the design of MS-Windows, of which your problems are only examples. Windows still follows the same design approach, and I believe it will still cause problems.
A browser may not be part of an operating system in some sense, but it's part of the Windows OS.
Exactly my point. Linux follows a nice, modular design. Different parts of the system are nicely separated from other parts of the system. They work together, but are not forced together, as they are with Windows. So, if my browser goes bonkers on Linux, I can just kill it and restart it. But when MSIE goes south, have the time you have to blow away your whole login session just to kill the browser, because it is also the OS shell.
Who said Win2K's backup couldn't understand it's own filesystem. Am I missing something here?
Quite a bit, apparently. Go back and read the web site I linked to. Which you obviously did not, which means you've been talking out of your nether regions this whole time. You're worse then an MS employee -- you're a troll. Go away.
Me:You don't use many OSes, do you? According to your own website, you've had Windows 2000 go bonkers. SVCHOST.EXE starting eating up all your RAM and CPU.
You:Uh, you've never used netscape have you?
You work for Microsoft, don't you? Well, in my book, the browser isn't part of the OS!
You:Uh, you could always get 3rd party backup software (or did Linux write all of GNU himself).
You miss the point. This guy goes around claiming Win2K is the best OS available, but its own backup program cannot understand its own filesystem? Yeah, I really want to trust my data to software of that quality.
I think it's [Win2K] the best thing ever to come out of Microsoft.
Could well be. That really isn't saying much. There is plenty of room for improvement in Windows. (Most would say that is an understatement.)
For that matter, it's the best OS currently on the market.
Really? You don't use many OSes, do you? According to your own website, you've had Windows 2000 go bonkers. SVCHOST.EXE starting eating up all your RAM and CPU. Very interesting, that.
You see, there are no mystery processes under Linux. There are no huge, monolithic programs that are part of the system. No single, huge "System Services Manager". So if you see something sucking up CPU time, you kill it. And if you need to find out what is wrong, you open up the source in the debugger and trace it. With Microsoft, when SVCHOST.EXE goes wonky, you do not and cannot determine what is wrong by examining the problem directly. You have to jump through hoops, like reinstalling the OS, for example.
Another thing about Linux: Linux backup software can handle file names longer then eight characters. I guess in Micros~1 land, that is too advanced to do.
I find it very interesting that you assert Win2K is the best OS on the market, when you yourself have encountered problems Linux has never had, and never will.
You:How do you type that way? That's gotta be slower.
Sure. But you see, most of my browsing isn't typing. I'm in input mode, sucking up information from the web. For the occasional keystroke during browsing, one-handed typing is just fine.
/me notes that I reached to the mouse to post this...
Sure. But that isn't browsing. That's entering a comment. When I switch tasks from browsing to typing, I put both hands back on the keyboard. Isn't that hard. The occasional task switch from mouse to keyboard and back again isn't significant, compared to the benefits you get from browsing with the mouse.
Of course, I really would prefer to have three arms, but until cyberbioengineering gets a lot more advanced, I'll have to live with it this way.:)
I mean, even on a celeron the interface is kindda sluggish don't you think? And although the page rendering is MUCH improved from nutscrape 4.x, it is also sluggish compared to the silky smooth IE5 rendering.
Yeah, and a car without tires is going to be pretty slow, too.
People, you have to realize something here: Mozilla IS NOT DONE YET.
People keep saying Mozilla is "too big", or "too slow", or "too buggy" to be considered a production browser.
You know what? You're right. And the Mozilla people agree with you. It isn't production code. Or perhaps you missed the twenty or so warnings about this being an UNFINISHED product when you went to download it?
Any programmer will tell you that you finish the program first. Then you test it. Then you get rid of the bugs. Then you test it again. Then you get rid of more bugs. Then you test it again. Then you optimize it for speed, size, or whatever floats your boat. Then you test it some more. You keep doing that, until it becomes a finished product. Then you ship.
Analying Mozilla in a development state, with tons of debug code, dead code, and unoptimized code all over the place, and who-knows-how-many pieces still lying around on the floor, is just plain wrong.
I don't barge in on you and criticize you when your work is half done. Give the Mozilla folks the same chance, eh?
From what I can see... Mozilla will not contain Java as it is proprietary to Sun.
Mozilla will not include Sun's JVM in the main distribution, because Sun won't let them. Sun's JVM license is too restrictive, and Sun seems to be doing everything in their power to make sure the rest of Java is as equally well controlled by them.
Keep in mind, Mozilla does support Java. You can use Mozilla with any OJI-compliant VM. The benefits of this are clear: - If you don't need Java, don't download it. - If you already have Java, don't download it. - If you do need it but don't have it, download it along with the Mozilla package. You don't waste any download time, as you'd have to download it anyway if they bundled it. - If Mozilla is updated, you don't need to re-download the JVM. - If the JVM is updated, you don't need to re-download Mozilla. - You can use multiple JVMs for development, testing, etc. - The JVM becomes a commodity product, able to be replaced at will. That is a Good Thing.
I find this rather disappointing.
I find Sun's treatment of Java (i.e., pretending to support it as a standard, and then pulling out when everyone has been suckered in) a lot more disappointing.
I understand the sentiments, but I don't think that a browser is fully functional without a JVM The browser needs to be distributed with a JVM, or it's not good from a Java perspective.
The browser needs to be distributed with Shockwave Flash, or it's not good from a Flash perspective.
The browser needs to be distributed with a VRML viewer, or it's not good from a VRML perspective.
The browser needs to be distributed with Windows, or it's not good from a Microsoft perspective.
As far as I am concerned, that argument is highly bogus. Please allow me the free will to make my own decisions, thank you very much.:)
... or kindness that can kill. I will choose a path that's clear; I will choose free will!" (With apologies to Niel Peart)
One major concern of several of these institutions going forward is the issue of browser compatibility.
And well it should be. I hope said institutions work strongly towards favoring standards compliant software, and only produce standards compliant content.
These institutions are VERY concerned about being able to continue filtering out browsers (primarily older browsers or those with known JavaScript problems) from their sites to keep support costs down.
Well, so much for the theory that standards compliance was the issue.:) The above shows that the institutions in question are less concerned with browser compatibility and are more concerned with cutting costs.
Filtering on USER_AGENT strings to find JavaScript problems is like filtering on the brand of your car to find emissions problems! "She's got a Toyota, I'm sure she is okay. Oh-oh, a Dodge, fail that one!"
You need to tell these instituions that they are going about things all wrong. Browsers are supposed to be a commodity item, despite what Microsoft is striving for. You should be able to switch browsers at will, and assuming the browser implements everything correctly, have no problems. And if the browser doesn't work correctly, you switch to one that does. That is why keeping the browser market a commodity market is so important.
The fact of the matter is, you can modify your USER_AGENT string right now! You can hack the binary and do a direct replacement, or you can use any of a number of proxy servers which can change the USER_AGENT string to report anything you want. Depending on USER_AGENT is an extremely bone-headed maneuver. USER_AGENT is designed for human consumption only. Don't use it to make content decisions.
With the advent of Mozilla and its inevitable widespread usage, fears of dozens, hundreds, maybe thousands of different "flavours" of Mozilla, with unknown problems (potentially) with JavaScript or perhaps other features that could cause support nightmares abound.
So say right up front, "We will not offer technical support, except for these browsers: X, Y, Z." That is to be expected. It is impossible for any company to test every possible program out there, and find which ones work and which ones do not. So if you've got a glitch, you have to make sure it isn't your software first. You do that by using a configuration the vendor has tested.
But trying to restrict access to a site based on the brand of browser is ludicris! Give us the free will to make our own choices, thank you very much. Don't let phantom fears about browser compatibility worry you.
(Sorry if I seem a bit miffed, but I am. As Tim Berners-Lee said so well, people who build pages built to work only on one kind of browser are hankering for the bad old days of computing, where a document produced by one system could not be read on another. We don't want to go there! We don't even want to get close. Stop the slide now, before you get deeper.)
You speak of checking sources in and out of the "core" (I assume you mean a revision control repository), and checking binaries out. You also mention keeping parse trees and similar temporary data structures in the repository as well.
We've really got two things here.
The first is the question of keeping just "source" files under revision control (and by source, I mean anything you use to build an executable - code, images, resources, etc.), or keeping everything (object files, final executables, etc.) under revision control.
The argument for "just source" is that you should always be able to build an identical finished product from the proper source, and so keeping generated output files around is a waste of machine resources. You also run into fewer problems with the unexpected dependencies and conflicts you encounter during debugging.
The argument for "everything" is that you can reduce build times by having those ouput files pre-generated, so the burden of rebuilding on a change is put on the person making the change, and everyone else just uses their output. You can also make the argument that finding the above-mentioned dependencies early on will lead to better code.
As far as I'm concerned, this is largely a matter of opinion, and you should go with whatever works for you.
Now, the second issue is a bit different. You talk about storing intermediate data, such as parse trees. An extension to the "everything under revision control" method. What benefit does this get you? If the source has changed, you are going to have to rebuild the output anyway. If the original has not changed, you can just use the object file from revision control. What is the point?
Now, I suppose you could argue that you don't always need to recompile an entire source file; you may have changed just one function. But to know that, the compiler is going to have to do a source analysis of it anyway, so why bother trying to cache the output? If your source files are big enough that this is a significant problem, youprobably need to look at splitting up your source a bit more. It isn't just increased build times that are at issue here; programmer comprehension drops the bigger a source file gets.
Don't get me wrong; I'm not trying to shoot you down here. I'm just trying to see what benefits one would get from the ideas you are suggesting.
Incidentally, Borland's Incremental Linker, used in C++Builder and Delphi, does do something similar to what you are suggesting. If you change one object file and go to relink to make an updated executable, it simply replaces the parts of the executable that depend on the changed object code. The parts that did not change stay the same. Saves a little time.
I do the exact same thing at present, and I find it to be an unacceptable solution to the parallel browsing problem, because it's so resource hungry and such a pain to manage all those windows (not to mention that probably 1 out of 5 times I close one of my open windows in netscape, it closes ALL my open windows. THIS DRIVES ME NUTS!).
Here are a few tips I have for Linux+Netscape users who have these problems:
* Download Netscape Navigator only -- not Communicator. The extra functions of Composer and Messenger appear to significantly decrease stability. I'm not saying I never have a crash, but it happens pretty infrequently. The Navigator-only version also has a smaller memory footprint.
* Close windows with the "File -> Close" menu command or the [ALT]+[W] keystroke combination. For some reason, using the standard window frame decoration "Close" icon seems to be more likely to cause a crash.
* If you are using Red Hat, make sure your fonts are sane. Your font catalogue in/etc/X11/fs/config should include all of the following: /usr/X11R6/lib/X11/fonts/misc:unscaled, /usr/X11R6/lib/X11/fonts/75dpi:unscaled, /usr/X11R6/lib/X11/fonts/100dpi:unscaled, /usr/X11R6/lib/X11/fonts/misc, /usr/X11R6/lib/X11/fonts/Type1, /usr/X11R6/lib/X11/fonts/Speedo, /usr/share/fonts/default/Type1, /usr/X11R6/lib/X11/fonts/100dpi, /usr/X11R6/lib/X11/fonts/75dpi, Make sure you have the appropriate RPM packages installed, that your font server is running, and that your XFree FontPath is pointed at your font server. This smoothes out some things, especially Java.
* Consider disabling the Java Virtual Machine (not JavaScript (well, you can disable it if you want to, but you don't have to)). Netscape's JVM still has trouble.
I agree that you shouldn't have to do this, but doing so has significantly improved stability for me. As the subject line suggests, it functions as a stopgap measure until a better Linux browser is available.
(BTW: I read your white paper. I've seen pre-caching software available for MS Windows. It isn't as smart as your system, but it is there. You might be able to coax something like a caching proxy server into doing what you want. Run HTTP through your proxy. Write a small program to accept a Netscape link via DND, and tell the proxy to fetch it ahead of time. Klunky, but it might work.)
Normally, I don't reply to ACs, but this is an exceptionally well-written post for an AC, so I will address it.
Having to take your hand away from the keyboard, and all the way over to the mouse.
Again: Leave your hand on the mouse. Use one hand for keyboarding, and one for mousing, and you'll find your browsing experience is much improved. If you refuse to do that, well, don't complain when the hammer makes a lousy screw driver.
Having to physically move the mouse.
Turn up your acceleration. I can cover the entire screen area of my 1600x1200 pixel desktop with small wrist movements. You're not using the mouse correctly; no wonder you have trouble with it.
I'd like to see how long it would have taken you to write that post of yours if you'd had to click each letter on some onscreen keyboard with your beloved mouse.
You're big on this whole "using a screwdriver to hammer in nails" technique, aren't you?
The thing that keeps me using IE is the fact that can go to a page that has a Flash object on it and IE will say "You don't have Flash, do you want it installed?" and it automagically does so if I say yes.
This is, in no way, shape, or form, a browser issue. This is an issue with ISV (Independent Software Vendor) support. ISVs are not supporting Linux, so you don't get your plugin.
Don't complain about the browser -- go gripe to those ISVs. You like their plugins so much, but when you ask them to support your platform of choice, they say, "F**k off". Personally, any company that does that to me, doesn't get my business. Maybe you like being told that, but I don't.
Blaming this on the browser is like blaming your car maker that the local gas station's service sucks.
(For the less-informed: Netscape on Linux supports that sort of "You don't have XYZ, but you need it, get it?" dialog, and has for quite some time.)
Navigator 1. Point with a minor wrist movement. 2. Click once.
Lynx 1. Down arrow. 2. Down arrow. 3. Down arrow. ... [edited for brevity]... 31. Down arrow. 32. Down arrow. 33. Press [ENTER].
Even if you turn on the link numbers, I find a simple point-and-click is just as fast as entering in a two or three digit number and pressing [ENTER]. Not to mention a lot easier. To say nothing of those interfaces which cannot easily be accomplished in text mode.
Since I'm here, let me also say...
1. download - hit d, Enter.
Click.
2. save rendered page to disk - hit p, enter, enter
[ALT]+[S]. Two in Navigator compared to three for Lynx.:)
3. add current doc to bookmark - a, d, enter
[ALT]+[K]. Again, Navigator wins.
4. add current link to bookmark file - a, l, enter
Press. Point. Release.
show source - \
[ALT]+[U]. Lynx wins by a mere keypress here.
6. Next page - space
Ditto.
revious page - b
[PGUP]
first page ctrl-A last page ctrl-E
Here you score a few points. These two work flawlessly with [CTRL]+[HOME] and [CTRL]+[END] under Windoze. For some reason known only to Netscape, Navigator on Linux ignores those keystrokes. Grrrrr.
reload is ctrl-R
[ALT]+[R] here, close enough.
redraw is ctrl-L
Not applicable.:)
quit is Q
[ALT]+[Q] to quit Navigator. I usually have it open all the time, so I don't do it much.
What's the keystroke to open a new window in Lynx? Oh yes, I forgot -- Lynx limits you to one window at a time.:) Which, for me, is unaccaptable. I middle-click as often as I left-click, sometimes. I usually have no less then four browser windows open at once. More then ten is not uncommon. (And, no, running multiple instances of Lynx in an xterm is not the same thing.)
I *can* use Netscape but it feels like a huge slow down to reach for a mouse every now and then.
Well, here's a tip -- stop using that screw driver to hammer in nails. Put one hand on the mouse, and keep it there.:) Keep your other hand over the keyboard. Ta-da!
Lynx is a fine browser, and has a lot of things going for it, but let's not by silly, here.
No commercially available DVD players will allow you to read or write the section that holds the keys. So, your copy will not have the keys, and other normal DVD players can't play the encrypted contents.
If no commercially available DVD hardware will read or write the keys, then what good does DeCSS do? If I cannot write to that area, then I cannot make a copy of that DVD no matter what I do, right? Because DVD players will not play a DVD without the proper keys, correct? The DVD CCA made sure that I cannot have an "unencrypted" movie, right?
Also: I have heard of DVD copying machines. They don't attempt to play the movie. They simply read in the DVD data bit-for-bit, and write an exact copy of it to the new media. We're talking about a relatively straight-forward extension of CD-R technology. So I don't think you need the keys to copy a DVD after all. Just because such machines aren't available through "normal channels" doesn't mean they don't exist.
Disclaimer: No, I haven't attempted to locate a supplier of DVD copying machines just to verify they exist. I am simply reporting reasonable information which I have heard. Yes, that makes it hearsay, but this is Slashdot, not a court.:)
XMMS is like an annoying amount of open source software nowadays...a cheap imitation of something that already exists (Winamp, in this case.)
No, XMMS is not like WinAmp. WinAmp is an MP3 player for Win32. XMMS is an MP3 player for POSIX and X.
More generally, if the only good programs are ones which do not build on existing concepts, we are in serious trouble. Thankfully, that is not the case.
I used to be a system operator of a dial-up BBS (bulletin board system), back when FidoNet was pretty much the only way to get online to any kind of WAN in places like back-woods New Hampshire, USA, where I live.
One of the things I've always liked about FidoNet over UseNet was that people were held accountable.
If you broke an echo's rules (an echo is like a newsgroup), the moderator of that echo could ban you from the echo. (Fido moderators are more like IRC channel operators then UseNet moderators).
If you got banned enough times, most system operators would simply ban you from the echos entirely.
But it got better. If a system's operator was unresponsive, or a system was a continual source of twits, the FidoNet feed to that system could be cut.
If other systems in the area kept refeeding him any, that entire network (local geographical area) would be cut.
Seems a little heavy-handed if you are used to Internet anarchy. But I think UseNet's system of waiting until things have deteriorated to the point of uselessness doesn't work, and a system that doesn't work isn't a good system. FidoNet preemptively cut off the garbage-makers. It was all run by the lose organization of system operators, was very grass-roots, and generally operated on concenus. It worked pretty well.
In a way, FidoNet has a cabal, and was better for it, IMNSHO.
Of course, the big-time (the Internet) has pretty much killed it off these days, so we'll never know how it would have scaled compared to Usenet.
It's inconceivable that broadcasters would simply stick with a single NTSC-quality signal and lease out the remaining bandwidth for wireless data. Who would buy it? It is still a one-way path from the transmitter to you.
Um, gee, the wireless communications market is only hotter then the core of the sun right now. I can't imagine what anyone would want all that bandwidth for./SARCASM
There is precisely one force driving any company: Money. Broadcast TV currently gets its money from advertising dollars. Will a high-definition signal pull in more ad viewers? No, people go for the programming. They want their ER and Ally McBeal. They don't care if it is broadcast in mono, stereo, or surround sound. They also don't care about the number of vertical scan lines. If they don't care, the advertisers don't care, and that means there is no good reason to offer HDTV, especially when you compare it to the previously noted white-hot wireless communications market.
Last night's X-files was available as hi-def TV to those who had digital TVs in the big markets.
I fail to see what that proves. All it says is they are willing to float a trial balloon to see what happens.
When the digital TV conversion is complete, you will see either the wide-screen HDTV picture or you will have four channels to choose from instead of one.
As has been observed by just about everybody, we don't need more channels, we need better content. (We being the American Public(TM), not the broadcasting industry.)
There are far more stations converting to digital than industry forecasts expected and the FCC Orders required.
The stations will have to convert to digital to pull off the swindle anyway, so that proves nothing.
I'd like to hope that we all end up living in a shiny happy world of HDTV, but the cynic in me thinks the All-Mighty Buck will take precedence.
I'm not familiar with the details of the case, but I don't see any way Microsoft's actions could be considered illegal.
As I understand it, this is Caldera's case:
First, it isn't that DR-DOS was incompatible with MS-DOS. It was that Microsoft put a check into MS-Windows to specficially detect third-party DOSes and disable Windows. Not because they were incompatible, but because they were competition.
Second, Microsoft is a monopoly. Since they own the market for Windows, excluding a competitor would do serious damage to that competior.
In the USA, it is not illegal to be a monopoly, but it is illegal to use that monopoly to compete. That was (in a nutshell) Caldera's case.
(Oh, and to whoever moderated the above post down as "Flamebait": Get a grip. Just because you don't agree with something doesn't mean it is a flame.)
I said that I don't believe Open Source will go far without also including open source design documentation.
I've wondered the same, but various projects seem to be show that you can have a working system without design documentation. It flys in the face of conventional software engineering wisdom, true, but it works.
I have done a little thinking and asking here, and have determined the following: The people doing the hacking seem to know where they are going intuitively. Mailing list discussions contain not only the design goals reached, but the decision-making process that lead up to it. OSS projects start out small, with a few developers, and grow exponentially as design goals become more obvious and modularization increases. It all seems very haphazard, but it does seem to work.
There is also no rule that says you cannot establish requirements, engineer a design, and then develop everything, all in an Open Source manner. However, it seems that the fewer people involved in those early stages, the better. Otherwise, you spend too much time fighting over which way the inevitable design trade-offs are going to go.
Can I ask when Mozilla will be done?
As I am fond of saying: Software is never done, it is only released. OSS does well because it not only accepts this, but embraces it.
And exactly why do we make browsers so complex that they may be arguably more complicated than the Linux kernel as was claimed?
The reason is that the browsing experience we have come to know and love is very high cohesion phenomenon. That is a fancy way of saying all the pieces of the browser get caught up in each other. An OS kernel is a fairly modularizable thing. Not so for a browser.
Of course, the requirement to have the mail and news functions done before the core browser can be released is slowing things down. That was the way they wanted to do things, and I'm not going to attack them for it at this point.:-)
Yes I do know people who write novels on their Palms, but I'm a believer in the computer adjusting to the way I want to use it, not the other way around.
Part of the problem with this is the small size of the Palm Pilot. It is designed to fit comfortably in your hand and your shirt pocket. With such a small size, "real" handwriting would be very difficult. There just isn't that much room to let you write out entire words. Letter-by-letter is pretty much the only practical way to go.
It should be possible to improve the letter-by-letter recognition part, though. Graffiti isn't hard to learn or use, but you are right, computers should adapt to the user whenever possible.
My only major complaint with the Newton was its size. If the Apple-Palm device comes to pass, this is what I'd like to see.... A screen the size of the Newton's...
Part of the problem here is you cannot carry five pounds in a three-pound bag. The big screen of the Newton was nice to work on, but it made the unit considerably larger, which meant it was hard to carry around.
Ever notice how the size of the Palm Pilot just about matches the size of a pocket notebook (the kind that flip open at the top)? There's a reason for that. It's a very convenient size for us humans, both to hold in our hands and to put in our pockets.
One thing that might be cool is a folding screen. Imagine a unit the thickness of the Palm V, but with twice the screen area. When you are done using it, fold it in half. You still couldn't hold it in the palm of your hand, but at least you could carry it around. Unfortunately, such folding screen technology is ten or twenty years off, from what I've heard.
Wired has an excellent article on this subject. It is a little old (Feb 1997) at this point, but as far as I know, still valid. Everyone should read this: The Great HDTV Swindle.
Here is a quick summary:
Conventional NTSC signals are analog. Frames are broadcast more or less as they are, and the timing signal is embedded in the carrier. DTV is Digital Television. By digitizing the signal, you can do things like compress it to save bandwidth, include program information, add additional data services, etc. HDTV is High Definition Television. It roughly doubles the number of vertical scan lines being broadcast, yielded a significantly better picture. It also allows different aspect ratios, so you don't have to clip or letterbox a movie to broadcast it.
Sounds real neat, right?
Not exactly. DTV compression allows HDTV to be broadcast in the roughly the same bandwidth as current TV channels. It also allows compression of NTSC signals. Rather then broadcasting HDTV in a full channel, a broadcaster can compress the NTSC signal, broadcast that using only one sixth of the channel, and lease the remaining bandwidth to wireless communications providers.
Given the limited initial demand for HDTV, what do you think the broadcasters are going to do? Waste all that bandwidth on a signal most are not going to use, or give us what we currently have and lots of extra money leasing their bandwidth? I know which one I would bet on.
So, if you think you are going to be seeing a better TV picture any time soon, think again. Except to spend lots of money to upgrade your equipment, but with zero reward.
Me:I disagree. I believe OSS wins because it does better at parallizing those tasks that can be parallized, not because it lacks deadlines.
You:You should have looked at Cox's argument more before posting this, because he addresses it. He says that free software is "always late", in that it's already not there to do the function that the programmer -- the "leader" -- wants.
I am starting to wonder if we are having two different conversations here.:-)
I still don't think this is invalidating Brooks's Law in any way, shape, or form. If 500 developers all decide they want to implement the printf() library from scratch, I am pretty sure you are going to see a mess, no matter how they work together, or how badly they itch to do so.
In the context of Brooks's Law, OSS works mainly because it finds the areas where the Law doesn't apply (i.e., testing and debugging, mainly), and distributes the workload there. Additionally, the lack of pressure from outside the development team keep Brooks's Law from coming into play (no manager to throw 10 new programmers your way).
The key here is, Brooks's Law is as potent as ever -- Open Source development finds ways to work around it that closed source development cannot use.
Slashdot Mirror
I said I did an emergency restore of my wonko.com backup. NOT my hard drive backup.
I figured a backup of your website would actually include your website. My mistake.
Me: You see, there are no mystery processes under Linux. There are no huge, monolithic programs that are part of the system. No single, huge "System Services Manager".
You: In fact, my friend, that is exactly what the Linux kernel is. Yes, the Linux kernel is a huge, monolithic program (thus the term "monolithic kernel") that contains a good deal of Linux's device support as well as a zillion other things.
Not quite the same thing.
Yes, the kernel is a monolithic kernel. That refers to the design of the memory management and scheduling of the kernel. All parts of the kernel share the same memory space and are scheduled together. This is one of the reasons Linux performs so well -- the kernel isn't preemptable, so there is no overhead of task switching in the kernel.
However, the kernel is still nicely modularized into separate components for software maintence, and compiles to a small binary that performs one task -- low-level device abstraction -- well. True, all of your low-level device abstraction is happening in the same program, but there really isn't a way around that. Device drivers have to have kernel privileges.
Comparing that to what I was referring to -- the many "monolithic" userland programs in Windows -- is an error. I was referring to the fact that there are a great many "do it all" processes in Windows which are essentially opaque, such as SVCHOST.EXE. You have no idea what they really do. You cannot get inside them to diagnose problems. They are a magic black box, which you are forced to trust. Hence the term "monolithic". Sorry if my usage confused you.
Now, there are various projects to include userland functionality -- knfsd, for NFS service, and khttpd, for web service -- in the Linux kernel, but I consider them the wrong solution to a problem. Fortunately, I don't have to include them in my kernel -- I can easily exclude them at compile-time, or not load them if I'm using pre-compiled modules.
That is another thing you cannot do with Windows -- you have to accept Microsoft's choices for what is and is not in the kernel. Such as the graphics layer. Originally, NT 3.x did not include the graphics subsystem in the NT kernel. This is one of the reasons NT 3.x was so slow, but it did mean better stability. However, MS decided to move parts of the GUI into the kernel itself with NT 4. This made things faster, but means there is a lot more that can go wrong in the critical kernel code.
Hmm. I guess you didn't read my article too well. I didn't use backup software to back up my files.
Hmmm. I guess you didn't write your article too well. I quote, "...installed Win2K, did an emergency restore of my wonko.com backup (which, luckily, was totally up to date)." Sure sounds like a Win2K backup program to me! How was I supposed to know that a totally up-to-date "backup" really meant you did a file copy after the problem happened? To me, a backup is something you do before problems occur.
(And before you start jumping up and down about your usage of "DOS" in the next sentence, realize that: MS still uses DOS today in some of its products. MS supports DOS programs under NT. MS has system recovery procedures that work with NT using DOS. Using a DOS-based program to run a system restore program is something they've done in the past. I didn't know you meant the actual MS-DOS(TM) product running instead of NT. I didn't think anybody still used stand-alone DOS.)
When I made that statement, I was referring to the final release of Windows 2000, which I am now using. My previous problems, as I've stated before, were with a beta version of the OS.
That is very true, but I believe the problems I describe are flaws in the design of MS-Windows, of which your problems are only examples. Windows still follows the same design approach, and I believe it will still cause problems.
A browser may not be part of an operating system in some sense, but it's part of the Windows OS.
Exactly my point. Linux follows a nice, modular design. Different parts of the system are nicely separated from other parts of the system. They work together, but are not forced together, as they are with Windows. So, if my browser goes bonkers on Linux, I can just kill it and restart it. But when MSIE goes south, have the time you have to blow away your whole login session just to kill the browser, because it is also the OS shell.
Who said Win2K's backup couldn't understand it's own filesystem. Am I missing something here?
Quite a bit, apparently. Go back and read the web site I linked to. Which you obviously did not, which means you've been talking out of your nether regions this whole time. You're worse then an MS employee -- you're a troll. Go away.
Me: You don't use many OSes, do you? According to your own website, you've had Windows 2000 go bonkers. SVCHOST.EXE starting eating up all your RAM and CPU.
You: Uh, you've never used netscape have you?
You work for Microsoft, don't you? Well, in my book, the browser isn't part of the OS!
You: Uh, you could always get 3rd party backup software (or did Linux write all of GNU himself).
You miss the point. This guy goes around claiming Win2K is the best OS available, but its own backup program cannot understand its own filesystem? Yeah, I really want to trust my data to software of that quality.
I think it's [Win2K] the best thing ever to come out of Microsoft.
Could well be. That really isn't saying much. There is plenty of room for improvement in Windows. (Most would say that is an understatement.)
For that matter, it's the best OS currently on the market.
Really? You don't use many OSes, do you? According to your own website, you've had Windows 2000 go bonkers. SVCHOST.EXE starting eating up all your RAM and CPU. Very interesting, that.
You see, there are no mystery processes under Linux. There are no huge, monolithic programs that are part of the system. No single, huge "System Services Manager". So if you see something sucking up CPU time, you kill it. And if you need to find out what is wrong, you open up the source in the debugger and trace it. With Microsoft, when SVCHOST.EXE goes wonky, you do not and cannot determine what is wrong by examining the problem directly. You have to jump through hoops, like reinstalling the OS, for example.
Another thing about Linux: Linux backup software can handle file names longer then eight characters. I guess in Micros~1 land, that is too advanced to do.
I find it very interesting that you assert Win2K is the best OS on the market, when you yourself have encountered problems Linux has never had, and never will.
Me: Leave your hand on the mouse
/me notes that I reached to the mouse to post this...
:)
You: How do you type that way? That's gotta be slower.
Sure. But you see, most of my browsing isn't typing. I'm in input mode, sucking up information from the web. For the occasional keystroke during browsing, one-handed typing is just fine.
Sure. But that isn't browsing. That's entering a comment. When I switch tasks from browsing to typing, I put both hands back on the keyboard. Isn't that hard. The occasional task switch from mouse to keyboard and back again isn't significant, compared to the benefits you get from browsing with the mouse.
Of course, I really would prefer to have three arms, but until cyberbioengineering gets a lot more advanced, I'll have to live with it this way.
I mean, even on a celeron the interface is kindda sluggish don't you think? And although the page rendering is MUCH improved from nutscrape 4.x, it is also sluggish compared to the silky smooth IE5 rendering.
Yeah, and a car without tires is going to be pretty slow, too.
People, you have to realize something here: Mozilla IS NOT DONE YET.
People keep saying Mozilla is "too big", or "too slow", or "too buggy" to be considered a production browser.
You know what? You're right. And the Mozilla people agree with you. It isn't production code. Or perhaps you missed the twenty or so warnings about this being an UNFINISHED product when you went to download it?
Any programmer will tell you that you finish the program first. Then you test it. Then you get rid of the bugs. Then you test it again. Then you get rid of more bugs. Then you test it again. Then you optimize it for speed, size, or whatever floats your boat. Then you test it some more. You keep doing that, until it becomes a finished product. Then you ship.
Analying Mozilla in a development state, with tons of debug code, dead code, and unoptimized code all over the place, and who-knows-how-many pieces still lying around on the floor, is just plain wrong.
I don't barge in on you and criticize you when your work is half done. Give the Mozilla folks the same chance, eh?
End of rant.
From what I can see... Mozilla will not contain Java as it is proprietary to Sun.
:)
Mozilla will not include Sun's JVM in the main distribution, because Sun won't let them. Sun's JVM license is too restrictive, and Sun seems to be doing everything in their power to make sure the rest of Java is as equally well controlled by them.
Keep in mind, Mozilla does support Java. You can use Mozilla with any OJI-compliant VM. The benefits of this are clear:
- If you don't need Java, don't download it.
- If you already have Java, don't download it.
- If you do need it but don't have it, download it along with the Mozilla package. You don't waste any download time, as you'd have to download it anyway if they bundled it.
- If Mozilla is updated, you don't need to re-download the JVM.
- If the JVM is updated, you don't need to re-download Mozilla.
- You can use multiple JVMs for development, testing, etc.
- The JVM becomes a commodity product, able to be replaced at will. That is a Good Thing.
I find this rather disappointing.
I find Sun's treatment of Java (i.e., pretending to support it as a standard, and then pulling out when everyone has been suckered in) a lot more disappointing.
I understand the sentiments, but I don't think that a browser is fully functional without a JVM The browser needs to be distributed with a JVM, or it's not good from a Java perspective.
The browser needs to be distributed with Shockwave Flash, or it's not good from a Flash perspective.
The browser needs to be distributed with a VRML viewer, or it's not good from a VRML perspective.
The browser needs to be distributed with Windows, or it's not good from a Microsoft perspective.
As far as I am concerned, that argument is highly bogus. Please allow me the free will to make my own decisions, thank you very much.
... or kindness that can kill. I will choose a path that's clear; I will choose free will!"
:) The above shows that the institutions in question are less concerned with browser compatibility and are more concerned with cutting costs.
(With apologies to Niel Peart)
One major concern of several of these institutions going forward is the issue of browser compatibility.
And well it should be. I hope said institutions work strongly towards favoring standards compliant software, and only produce standards compliant content.
These institutions are VERY concerned about being able to continue filtering out browsers (primarily older browsers or those with known JavaScript problems) from their sites to keep support costs down.
Well, so much for the theory that standards compliance was the issue.
Filtering on USER_AGENT strings to find JavaScript problems is like filtering on the brand of your car to find emissions problems! "She's got a Toyota, I'm sure she is okay. Oh-oh, a Dodge, fail that one!"
You need to tell these instituions that they are going about things all wrong. Browsers are supposed to be a commodity item, despite what Microsoft is striving for. You should be able to switch browsers at will, and assuming the browser implements everything correctly, have no problems. And if the browser doesn't work correctly, you switch to one that does. That is why keeping the browser market a commodity market is so important.
The fact of the matter is, you can modify your USER_AGENT string right now! You can hack the binary and do a direct replacement, or you can use any of a number of proxy servers which can change the USER_AGENT string to report anything you want. Depending on USER_AGENT is an extremely bone-headed maneuver. USER_AGENT is designed for human consumption only. Don't use it to make content decisions.
With the advent of Mozilla and its inevitable widespread usage, fears of dozens, hundreds, maybe thousands of different "flavours" of Mozilla, with unknown problems (potentially) with JavaScript or perhaps other features that could cause support nightmares abound.
So say right up front, "We will not offer technical support, except for these browsers: X, Y, Z." That is to be expected. It is impossible for any company to test every possible program out there, and find which ones work and which ones do not. So if you've got a glitch, you have to make sure it isn't your software first. You do that by using a configuration the vendor has tested.
But trying to restrict access to a site based on the brand of browser is ludicris! Give us the free will to make our own choices, thank you very much. Don't let phantom fears about browser compatibility worry you.
(Sorry if I seem a bit miffed, but I am. As Tim Berners-Lee said so well, people who build pages built to work only on one kind of browser are hankering for the bad old days of computing, where a document produced by one system could not be read on another. We don't want to go there! We don't even want to get close. Stop the slide now, before you get deeper.)
You speak of checking sources in and out of the "core" (I assume you mean a revision control repository), and checking binaries out. You also mention keeping parse trees and similar temporary data structures in the repository as well.
We've really got two things here.
The first is the question of keeping just "source" files under revision control (and by source, I mean anything you use to build an executable - code, images, resources, etc.), or keeping everything (object files, final executables, etc.) under revision control.
The argument for "just source" is that you should always be able to build an identical finished product from the proper source, and so keeping generated output files around is a waste of machine resources. You also run into fewer problems with the unexpected dependencies and conflicts you encounter during debugging.
The argument for "everything" is that you can reduce build times by having those ouput files pre-generated, so the burden of rebuilding on a change is put on the person making the change, and everyone else just uses their output. You can also make the argument that finding the above-mentioned dependencies early on will lead to better code.
As far as I'm concerned, this is largely a matter of opinion, and you should go with whatever works for you.
Now, the second issue is a bit different. You talk about storing intermediate data, such as parse trees. An extension to the "everything under revision control" method. What benefit does this get you? If the source has changed, you are going to have to rebuild the output anyway. If the original has not changed, you can just use the object file from revision control. What is the point?
Now, I suppose you could argue that you don't always need to recompile an entire source file; you may have changed just one function. But to know that, the compiler is going to have to do a source analysis of it anyway, so why bother trying to cache the output? If your source files are big enough that this is a significant problem, youprobably need to look at splitting up your source a bit more. It isn't just increased build times that are at issue here; programmer comprehension drops the bigger a source file gets.
Don't get me wrong; I'm not trying to shoot you down here. I'm just trying to see what benefits one would get from the ideas you are suggesting.
Incidentally, Borland's Incremental Linker, used in C++Builder and Delphi, does do something similar to what you are suggesting. If you change one object file and go to relink to make an updated executable, it simply replaces the parts of the executable that depend on the changed object code. The parts that did not change stay the same. Saves a little time.
I do the exact same thing at present, and I find it to be an unacceptable solution to the parallel browsing problem, because it's so resource hungry and such a pain to manage all those windows (not to mention that probably 1 out of 5 times I close one of my open windows in netscape, it closes ALL my open windows. THIS DRIVES ME NUTS!).
/etc/X11/fs/config should include all of the following:
/usr/X11R6/lib/X11/fonts/misc:unscaled,
/usr/X11R6/lib/X11/fonts/75dpi:unscaled,
/usr/X11R6/lib/X11/fonts/100dpi:unscaled,
/usr/X11R6/lib/X11/fonts/misc,
/usr/X11R6/lib/X11/fonts/Type1,
/usr/X11R6/lib/X11/fonts/Speedo,
/usr/share/fonts/default/Type1,
/usr/X11R6/lib/X11/fonts/100dpi,
/usr/X11R6/lib/X11/fonts/75dpi,
Here are a few tips I have for Linux+Netscape users who have these problems:
* Download Netscape Navigator only -- not Communicator. The extra functions of Composer and Messenger appear to significantly decrease stability. I'm not saying I never have a crash, but it happens pretty infrequently. The Navigator-only version also has a smaller memory footprint.
* Close windows with the "File -> Close" menu command or the [ALT]+[W] keystroke combination. For some reason, using the standard window frame decoration "Close" icon seems to be more likely to cause a crash.
* If you are using Red Hat, make sure your fonts are sane. Your font catalogue in
Make sure you have the appropriate RPM packages installed, that your font server is running, and that your XFree FontPath is pointed at your font server. This smoothes out some things, especially Java.
* Consider disabling the Java Virtual Machine (not JavaScript (well, you can disable it if you want to, but you don't have to)). Netscape's JVM still has trouble.
I agree that you shouldn't have to do this, but doing so has significantly improved stability for me. As the subject line suggests, it functions as a stopgap measure until a better Linux browser is available.
(BTW: I read your white paper. I've seen pre-caching software available for MS Windows. It isn't as smart as your system, but it is there. You might be able to coax something like a caching proxy server into doing what you want. Run HTTP through your proxy. Write a small program to accept a Netscape link via DND, and tell the proxy to fetch it ahead of time. Klunky, but it might work.)
Normally, I don't reply to ACs, but this is an exceptionally well-written post for an AC, so I will address it.
Having to take your hand away from the keyboard, and all the way over to the mouse.
Again: Leave your hand on the mouse. Use one hand for keyboarding, and one for mousing, and you'll find your browsing experience is much improved. If you refuse to do that, well, don't complain when the hammer makes a lousy screw driver.
Having to physically move the mouse.
Turn up your acceleration. I can cover the entire screen area of my 1600x1200 pixel desktop with small wrist movements. You're not using the mouse correctly; no wonder you have trouble with it.
I'd like to see how long it would have taken you to write that post of yours if you'd had to click each letter on some onscreen keyboard with your beloved mouse.
You're big on this whole "using a screwdriver to hammer in nails" technique, aren't you?
The thing that keeps me using IE is the fact that can go to a page that has a Flash object on it and IE will say "You don't have Flash, do you want it installed?" and it automagically does so if I say yes.
This is, in no way, shape, or form, a browser issue. This is an issue with ISV (Independent Software Vendor) support. ISVs are not supporting Linux, so you don't get your plugin.
Don't complain about the browser -- go gripe to those ISVs. You like their plugins so much, but when you ask them to support your platform of choice, they say, "F**k off". Personally, any company that does that to me, doesn't get my business. Maybe you like being told that, but I don't.
Blaming this on the browser is like blaming your car maker that the local gas station's service sucks.
(For the less-informed: Netscape on Linux supports that sort of "You don't have XYZ, but you need it, get it?" dialog, and has for quite some time.)
The reason is that lynx has a much better UI. First of all, navigation is done with keyboard - which is inherently faster than mouse...
...
:)
:)
:) Which, for me, is unaccaptable. I middle-click as often as I left-click, sometimes. I usually have no less then four browser windows open at once. More then ten is not uncommon. (And, no, running multiple instances of Lynx in an xterm is not the same thing.)
:) Keep your other hand over the keyboard. Ta-da!
Oh, come on. That old argument again? One might as well say that a screw driver in inherently faster then a hammer.
Go to a page with dozens of links on it, pick a link at random, and compare the navigation between Lynx and Navigator:
Navigator
1. Point with a minor wrist movement.
2. Click once.
Lynx
1. Down arrow.
2. Down arrow.
3. Down arrow.
... [edited for brevity]
31. Down arrow.
32. Down arrow.
33. Press [ENTER].
Even if you turn on the link numbers, I find a simple point-and-click is just as fast as entering in a two or three digit number and pressing [ENTER]. Not to mention a lot easier. To say nothing of those interfaces which cannot easily be accomplished in text mode.
Since I'm here, let me also say...
1. download - hit d, Enter.
Click.
2. save rendered page to disk - hit p, enter, enter
[ALT]+[S]. Two in Navigator compared to three for Lynx.
3. add current doc to bookmark - a, d, enter
[ALT]+[K]. Again, Navigator wins.
4. add current link to bookmark file - a, l, enter
Press. Point. Release.
show source - \
[ALT]+[U]. Lynx wins by a mere keypress here.
6. Next page - space
Ditto.
revious page - b
[PGUP]
first page ctrl-A
last page ctrl-E
Here you score a few points. These two work flawlessly with [CTRL]+[HOME] and [CTRL]+[END] under Windoze. For some reason known only to Netscape, Navigator on Linux ignores those keystrokes. Grrrrr.
reload is ctrl-R
[ALT]+[R] here, close enough.
redraw is ctrl-L
Not applicable.
quit is Q
[ALT]+[Q] to quit Navigator. I usually have it open all the time, so I don't do it much.
What's the keystroke to open a new window in Lynx? Oh yes, I forgot -- Lynx limits you to one window at a time.
I *can* use Netscape but it feels like a huge slow down to reach for a mouse every now and then.
Well, here's a tip -- stop using that screw driver to hammer in nails. Put one hand on the mouse, and keep it there.
Lynx is a fine browser, and has a lot of things going for it, but let's not by silly, here.
No commercially available DVD players will allow you to read or write the section that holds the keys. So, your copy will not have the keys, and other normal DVD players can't play the encrypted contents.
:)
If no commercially available DVD hardware will read or write the keys, then what good does DeCSS do? If I cannot write to that area, then I cannot make a copy of that DVD no matter what I do, right? Because DVD players will not play a DVD without the proper keys, correct? The DVD CCA made sure that I cannot have an "unencrypted" movie, right?
Also: I have heard of DVD copying machines. They don't attempt to play the movie. They simply read in the DVD data bit-for-bit, and write an exact copy of it to the new media. We're talking about a relatively straight-forward extension of CD-R technology. So I don't think you need the keys to copy a DVD after all. Just because such machines aren't available through "normal channels" doesn't mean they don't exist.
Disclaimer: No, I haven't attempted to locate a supplier of DVD copying machines just to verify they exist. I am simply reporting reasonable information which I have heard. Yes, that makes it hearsay, but this is Slashdot, not a court.
XMMS is like an annoying amount of open source software nowadays...a cheap imitation of something that already exists (Winamp, in this case.)
No, XMMS is not like WinAmp. WinAmp is an MP3 player for Win32. XMMS is an MP3 player for POSIX and X.
More generally, if the only good programs are ones which do not build on existing concepts, we are in serious trouble. Thankfully, that is not the case.
I used to be a system operator of a dial-up BBS (bulletin board system), back when FidoNet was pretty much the only way to get online to any kind of WAN in places like back-woods New Hampshire, USA, where I live.
One of the things I've always liked about FidoNet over UseNet was that people were held accountable.
If you broke an echo's rules (an echo is like a newsgroup), the moderator of that echo could ban you from the echo. (Fido moderators are more like IRC channel operators then UseNet moderators).
If you got banned enough times, most system operators would simply ban you from the echos entirely.
But it got better. If a system's operator was unresponsive, or a system was a continual source of twits, the FidoNet feed to that system could be cut.
If other systems in the area kept refeeding him any, that entire network (local geographical area) would be cut.
Seems a little heavy-handed if you are used to Internet anarchy. But I think UseNet's system of waiting until things have deteriorated to the point of uselessness doesn't work, and a system that doesn't work isn't a good system. FidoNet preemptively cut off the garbage-makers. It was all run by the lose organization of system operators, was very grass-roots, and generally operated on concenus. It worked pretty well.
In a way, FidoNet has a cabal, and was better for it, IMNSHO.
Of course, the big-time (the Internet) has pretty much killed it off these days, so we'll never know how it would have scaled compared to Usenet.
It's inconceivable that broadcasters would simply stick with a single NTSC-quality signal and lease out the remaining bandwidth for wireless data. Who would buy it? It is still a one-way path from the transmitter to you.
/SARCASM
Um, gee, the wireless communications market is only hotter then the core of the sun right now. I can't imagine what anyone would want all that bandwidth for.
There is precisely one force driving any company: Money. Broadcast TV currently gets its money from advertising dollars. Will a high-definition signal pull in more ad viewers? No, people go for the programming. They want their ER and Ally McBeal. They don't care if it is broadcast in mono, stereo, or surround sound. They also don't care about the number of vertical scan lines. If they don't care, the advertisers don't care, and that means there is no good reason to offer HDTV, especially when you compare it to the previously noted white-hot wireless communications market.
Last night's X-files was available as hi-def TV to those who had digital TVs in the big markets.
I fail to see what that proves. All it says is they are willing to float a trial balloon to see what happens.
When the digital TV conversion is complete, you will see either the wide-screen HDTV picture or you will have four channels to choose from instead of one.
As has been observed by just about everybody, we don't need more channels, we need better content. (We being the American Public(TM), not the broadcasting industry.)
There are far more stations converting to digital than industry forecasts expected and the FCC Orders required.
The stations will have to convert to digital to pull off the swindle anyway, so that proves nothing.
I'd like to hope that we all end up living in a shiny happy world of HDTV, but the cynic in me thinks the All-Mighty Buck will take precedence.
I'm not familiar with the details of the case, but I don't see any way Microsoft's actions could be considered illegal.
As I understand it, this is Caldera's case:
First, it isn't that DR-DOS was incompatible with MS-DOS. It was that Microsoft put a check into MS-Windows to specficially detect third-party DOSes and disable Windows. Not because they were incompatible, but because they were competition.
Second, Microsoft is a monopoly. Since they own the market for Windows, excluding a competitor would do serious damage to that competior.
In the USA, it is not illegal to be a monopoly, but it is illegal to use that monopoly to compete. That was (in a nutshell) Caldera's case.
(Oh, and to whoever moderated the above post down as "Flamebait": Get a grip. Just because you don't agree with something doesn't mean it is a flame.)
I said that I don't believe Open Source will go far without also including open source design documentation.
:-)
I've wondered the same, but various projects seem to be show that you can have a working system without design documentation. It flys in the face of conventional software engineering wisdom, true, but it works.
I have done a little thinking and asking here, and have determined the following: The people doing the hacking seem to know where they are going intuitively. Mailing list discussions contain not only the design goals reached, but the decision-making process that lead up to it. OSS projects start out small, with a few developers, and grow exponentially as design goals become more obvious and modularization increases. It all seems very haphazard, but it does seem to work.
There is also no rule that says you cannot establish requirements, engineer a design, and then develop everything, all in an Open Source manner. However, it seems that the fewer people involved in those early stages, the better. Otherwise, you spend too much time fighting over which way the inevitable design trade-offs are going to go.
Can I ask when Mozilla will be done?
As I am fond of saying: Software is never done, it is only released. OSS does well because it not only accepts this, but embraces it.
And exactly why do we make browsers so complex that they may be arguably more complicated than the Linux kernel as was claimed?
The reason is that the browsing experience we have come to know and love is very high cohesion phenomenon. That is a fancy way of saying all the pieces of the browser get caught up in each other. An OS kernel is a fairly modularizable thing. Not so for a browser.
Of course, the requirement to have the mail and news functions done before the core browser can be released is slowing things down. That was the way they wanted to do things, and I'm not going to attack them for it at this point.
Yes I do know people who write novels on their Palms, but I'm a believer in the computer adjusting to the way I want to use it, not the other way around.
Part of the problem with this is the small size of the Palm Pilot. It is designed to fit comfortably in your hand and your shirt pocket. With such a small size, "real" handwriting would be very difficult. There just isn't that much room to let you write out entire words. Letter-by-letter is pretty much the only practical way to go.
It should be possible to improve the letter-by-letter recognition part, though. Graffiti isn't hard to learn or use, but you are right, computers should adapt to the user whenever possible.
My only major complaint with the Newton was its size. If the Apple-Palm device comes to pass, this is what I'd like to see.... A screen the size of the Newton's...
Part of the problem here is you cannot carry five pounds in a three-pound bag. The big screen of the Newton was nice to work on, but it made the unit considerably larger, which meant it was hard to carry around.
Ever notice how the size of the Palm Pilot just about matches the size of a pocket notebook (the kind that flip open at the top)? There's a reason for that. It's a very convenient size for us humans, both to hold in our hands and to put in our pockets.
One thing that might be cool is a folding screen. Imagine a unit the thickness of the Palm V, but with twice the screen area. When you are done using it, fold it in half. You still couldn't hold it in the palm of your hand, but at least you could carry it around. Unfortunately, such folding screen technology is ten or twenty years off, from what I've heard.
Wired has an excellent article on this subject. It is a little old (Feb 1997) at this point, but as far as I know, still valid. Everyone should read this: The Great HDTV Swindle.
Here is a quick summary:
Conventional NTSC signals are analog. Frames are broadcast more or less as they are, and the timing signal is embedded in the carrier. DTV is Digital Television. By digitizing the signal, you can do things like compress it to save bandwidth, include program information, add additional data services, etc. HDTV is High Definition Television. It roughly doubles the number of vertical scan lines being broadcast, yielded a significantly better picture. It also allows different aspect ratios, so you don't have to clip or letterbox a movie to broadcast it.
Sounds real neat, right?
Not exactly. DTV compression allows HDTV to be broadcast in the roughly the same bandwidth as current TV channels. It also allows compression of NTSC signals. Rather then broadcasting HDTV in a full channel, a broadcaster can compress the NTSC signal, broadcast that using only one sixth of the channel, and lease the remaining bandwidth to wireless communications providers.
Given the limited initial demand for HDTV, what do you think the broadcasters are going to do? Waste all that bandwidth on a signal most are not going to use, or give us what we currently have and lots of extra money leasing their bandwidth? I know which one I would bet on.
So, if you think you are going to be seeing a better TV picture any time soon, think again. Except to spend lots of money to upgrade your equipment, but with zero reward.
What, like "Start Me Up"?
I always thought it somewhat appropriate that the line immediately following "Start Me Up" in that song talks about grown men crying.
Me: I disagree. I believe OSS wins because it does better at parallizing those tasks that can be parallized, not because it lacks deadlines.
:-)
You: You should have looked at Cox's argument more before posting this, because he addresses it. He says that free software is "always late", in that it's already not there to do the function that the programmer -- the "leader" -- wants.
I am starting to wonder if we are having two different conversations here.
I still don't think this is invalidating Brooks's Law in any way, shape, or form. If 500 developers all decide they want to implement the printf() library from scratch, I am pretty sure you are going to see a mess, no matter how they work together, or how badly they itch to do so.
In the context of Brooks's Law, OSS works mainly because it finds the areas where the Law doesn't apply (i.e., testing and debugging, mainly), and distributes the workload there. Additionally, the lack of pressure from outside the development team keep Brooks's Law from coming into play (no manager to throw 10 new programmers your way).
The key here is, Brooks's Law is as potent as ever -- Open Source development finds ways to work around it that closed source development cannot use.