Many wireless keyboards come with a fully functional PS/2 (or USB) base. Whether the keyboard is present or not, the simple presence of the base is sufficient to get past the BIOS.
I picked up one from CompUSA a few years ago for about $20. The keyboard has since died, but the base still works fine for my server. Remember, the keyboard quality doesn't matter here. Who cares if the wireless has a range of two feet if you don't want it for its wireless abilities?
IR has the advantage of allowing keyboard access when you want it too. Or, if you absolutely don't want it, duct tape on the photoreceptor works wonders.
What is a desktop icon if not just another form of link. What makes one link more special than another?
If XHTML is used for presentation, CSS is used for styling, DOM is used for the model, and scripting is used for logic, I don't see the problem. I thought you were complaining that there were too many technologies. Now it seems you are complaining that there are too few. From what you describe, it sounds like you would prefer a presentation and styling framework for web pages and a completely independent and different framework that does the same thing for applications only it adds logic and a data model. Does that make sense to you?
If you want to simplify, just use XHTML and CSS. Done. There's your online document. Simple as can be. With standards.
Want some dynamism? Want interaction? Add in scripting and voila! You have entered into the world of applications. For what is an application if not a way to receive, process, and send information? What it tells us is that it doesn't have to be either a web document or an application, 1 or 0, black or white. You can already make a web application that is functionally indistiguishable from most native applications. You can also make a hybrid model which is really what most authoring and reporting tools are after all.
Okay, first off, pointing to one particular page which isn't even standards compliant does not improve your argument.
Second, 100K easily fits into CPU cache let alone causing an issue for hundreds of megabytes of main memory. (And no, I don't think that's how CPU cache is effectively used. I just used it as a point of reference.)
Third, it compresses down to less than 20K using standard gzip compression. This equates to three seconds of download time on a 56Kbps modem connecting at 52Kbps. So yes, it could be more efficient, but come on.
Let's take a standards-compliant site like CSS Zen Garden or GeekSpeak.org. When someone actually bothers to reference the standards, you end up with a site with comparatively little markup. Both sites are less than 20K of markup and easily compress to less than 10K. Both are static pages, yes. But then again, so was your Spiegel reference.
With standards. Both are static pages, yes. But then again, so was your Spiegel reference.
What bloat do you see on those pages? How complex is the markup? How well do they stand up with accessibility? (Answer: very well) Both referenced sites are smaller than Spiegel's, but then Spiegel's is much older and established. Same story as with Amazon and eBay, inertia can be the biggest enemy no matter what direction you choose.
Re:Great.. A world of proprietary apps
on
Browser Wars 2004
·
· Score: 1
1. Consolidation of existing standards? Almost all new specs are XML-based and build upon existing technologies. As for cranking so many out, what does it matter? CSS2, DOM, SVG, XSL:FO, XSLT, etc. are all solutions to a particular problem set. That said, XSL:FO and CSS (for example) use many of the same attribute names. The markup languages all rely upon a common namespace spec. I don't see the problem. Can you be more specific?
1b. CSS has transparency. In CSS, the attribute is called "opacity". It's in CSS3. IE, Mozilla/Firefox, and Safari have all have support for transparency through proprietary extensions. Currently Safari 1.1+ and the newest versions of Mozilla/Firefox support the W3C directive as well.
Multicolor gradients in CSS is a bad idea in my humble opinion. Better to simply keep with CSS3's background image scaling and supply a SVG gradient. More flexible and doesn't mix concerns.
Embedding fonts has always been a political/economic issue rather than a technical one. Both IE and Netscape had competing dynamic font technology, but due to licensing fees demanded by the creators of the various fonts, most web developers decided to go without and use an image instead.
I agree about the CMYK and multi-column layout, but disagree about the printing. CSS is used for print output as well, but it's just that print isn't the only target. That support could definitely be much stronger though.
I personally think that the death of Java on the browser was a horrible thing. No, I don't bemoan the death of applets. I considered the lack of Java on the browser due to applets akin to throwing the baby out with the bathwater. Hmmm... Portable code, small size, large set of usable APIs... As long as the browser's main rendering engine was the presentation layer, the Java was the business logic, and some scripting language was the glue, I'd be happier than a pig in slop. I mean, be honest. What real portability problems have you seen in Java outside of the GUI? IBM's DirectDOM project held so much promise in this regard. Died in the womb though.
2. Am I to understand that you are blaming the technologies as being inadequate because Slashdot doesn't use them? eBay, Amazon, and Slashdot were all born before the DOM and CSS had become common. To retool each site would require a great deal of effort that would not necessarily make good business sense. Better for someone to start from scratch...like Gmail. Blogger has been adding some interesting editing choices as well in the last few months.
2b. Flash and Actionscript are faulty because of the technology or because elitist programmers prejudge it and thus don't make anything worthwhile. Me personally, I think that Flash movies can be great things: smaller than an MPEG or Quicktime video, easily scalable to multiple resolutions, easy to synchronize audio and video, and a full scripting engine to boot. I think you wrote this technology off far too quickly my friend. As far as "didn't catch on," how can it be in the vast majority of browsers, on every major browser platform, and every major desktop operating system and still be seen as not catching on? Because some people overuse Flash for ads and splash screens, this invalidates the whole technology? It was used for splash screens and ads precisely because it already caught on years ago.
2c. Web services are tied into the OS, yes. But on the server-side. There is no technical reason why this must be true on the client. In fact, since you never know if a Mac user will find your information useful or if a Linux user would want to purchase your wares, it makes sense to make sure that cross-client technologies like DOM and Javascript are used. The only trouble comes from absent-mindedly using IE-specific extensions.
As far as Longhorn is concerned, may I remind you that Longhorn will not be released in 2004. Or 2005. And maybe not 2006. And then you'll wait a few years for the desktops to catch up. The next Mac OS, Tiger
Which reminds me: we've been hearing for years from people on usenet and various mailing lists that HTML content was horrible, that their clients ended up with the raw markup which was unintelligible, and archiving of HTML email was prohibitively difficult. We've been hearing this for like what? Eight years?
The most vocal of this group have been the technological elite, right? These are the ones that continually browbeat newcomers about how their email/news client is ruining everything.
To those folks I ask this one simple question: Why didn't you write a text-based email/news client eight years ago that strips the tags or (simpler) detects when there is a plain-text MIME segment? End of problem on both ends.
Almost every technology for the web has made things more complicated? (X)HTML specs have been steadily removing elements for years -- making them simpler. Why? Because putting style information in markup makes things complicated. CSS is styling and nothing else. Simpler.
The DOM is your example of incompatibility? Take IE 6 and compare it to the ECMAScript/JavaScript standard. Do the same with Firefox. Amazing. They both follow at least 99% of the spec.
You speak of not needed an HTML page 'in between' for the info. You're right. But I keep getting this strange feeling that in place of the HTML (or other markup), you would have layout and functionality embedded in some programming language. No thank you. I remember what that was like, and I have no intention of going back to those days. I'd much rather specify my UI in a semantic markup and style it with CSS or something like it....
I'm sorry... I took a moment to finish laughing at your "wasting gazillion of Terrabytes" comment. A properly configured web server compresses the HTML that comes out of it. And even if it didn't, we're still talking about numbers so small that even modem users don't care much. It's the graphics, movies, and audio clips that "waste" bandwidth, not the markup. The great thing about site-wide JavaScript files and CSS stylesheets is that they only need to be downloaded once.
As for focusing on "sending and communicating the truely wanted data as direct, speedy and interactive as possible - without any unnecessary wrappers," I encourage you to lookup up techniques such as background page loads and their ilk. In fact, if XML were to bug you too much because of the perceived bloat (see note about compressing markup earlier), you could always just wrap a tab-delimited file in a single tag and split the results after the file comes down. It could suck if/when you want to add new fields, but you could do it. And there you go, no bloat. Bottom line: client and server can talk directly. People simply haven't yet while older browsers were still around to gum up the works.
[HyperText] was never meant for (web) applications.
No, but it also wasn't meant for just documents and news. It was for presenting information. Whether that information is part of a news page or part of an Amazon query result, why should we or the markup care?
Re:Great.. A world of proprietary apps
on
Browser Wars 2004
·
· Score: 1
Oke, let's form some rebuttals here:
1. Browsers: What would be more perfect to you? I'm not saying you are wrong, but I doubt you would come up with a radical new approach that wouldn't immediately turn people off. Click to go to a new page based on content context. Click "back" to go back. URL autocompletion. Tabbed browsing. Mouse gestures. What exactly is so deficient, and more importantly, what is your proposed solution?
As for CSS, it wasn't meant to generate primitive shapes. That's what SVG was meant for. What's the alternative? Primitive shapes in CSS like triangles, circles, elipses, pentagons, hexagons, dodecahedrons, etc.? What is a basic shape to you? I guarantee that as soon as you decide, someone else will pop out of the woodwork and proclaim that it's not enough. Personally, I think the existing spec can handle quite a lot as it is.
Postscript is primarily a print format. CSS is not just for print publishing. For example, are there postscript directives specifically for text (aural) readers? Does postscript keep the content separate from the presentation or are they inextricably tied together? Apples and oranges in my opinion.
2. Web Applications: Going beyond the page metaphor isn't hard with the DOM. As for removing the browser, Microsoft has been doing this for years with the componentization of their rendering widget. The Mozilla group have a toolkit based upon XUL and XPCOM. Multiple applications have taken Mozilla's rendering widget and made non-browser apps. Flash is showing great promise with their ActionScript and XML handling features (based on DOM by the way). The fact remains that application development is easier on a browser than just about anywhere else.
The issue I see isn't that Macromedia needs to produce a decent programming tool. The power of web applications is that the technologies are already used and practiced by hundreds of web developers around the world. This is the strength of Apple's Dashboard work. I see the issue more as one where developers at large haven't moved beyond the page metaphor, not that the technology hasn't.
Those of you who use Gmail can relate to me here. I very much believe that they're pushing past the page metaphor in impressive ways like expanding conversation threads without refreshing the browser window, checking spelling seamlessly, etc. It's to the credit of the Gmail team (among others) that they realized that the number of browsers that can functionally handle advanced scripting and use a standard set of APIs has finally hit critical mass.
As for ditching the browser, here is an interface that everyone knows and understands today. Here is a piece of software so ubiquitous, that it is more common than an email client on desktops and kiosks. Now you're saying we should drop this advantage and go backward to a time of greater balkanization because what we have doesn't solve even problem perfectly? That's the solution: dump it and get something new from scratch? If I click on a link and it opens a new browser window without the default navigation buttons or taskbar, how is this worse? How is this distinguishable to the general public from a "real" application on their computer? How would your ideal framework be fundamentally different from the same window only launched from a desktop icon instead of a hyperlink?
Yes, I can acknowledge things like local filesystem access. This is a need for a framework outside of the browser. Except...well...Mozilla, Microsoft, Macromedia et al have already solved it. Pick your flavor. They all work. In fact, they all work in much the same way: some markup, some scripting (usually accessing the DOM or a thin layer on top of it), and some external styling. However, this doesn't invalidate all browser application development. It just means that there is no single silver bullet.
I agree with you and others that browsers won't go away. In fact, I sincerely hope they don't.
Re:Not ONLY Faster, lighter, but also IE-compatibl
on
Browser Wars 2004
·
· Score: 1
...the only way to compete with IE is being able to render the pages exactly like IE does.
Which IE? Seriously. Show me someone who can say with a straight face that every version of IE renders exactly alike. Take a copy of IE4, IE 5, IE 5.5, IE 4 for the Mac, IE 5 for the Mac, etc. and compare it to a copy of IE 6 when using a non-trivial amount of CSS. Just keeping with MS Windows, the differences are substantial.
So if an alternate browser is to render exactly like IE, I must ask, "Which version of IE?"
I don't know about that. I was "around" in the mid-90s. Yes, Netscape had its share of exploits (mostly Javascript), but Netscape's main faults were crashing and lack of features (like good CSS support).
On the other hand, MSIE has had more than its share of scripting exploits. In addition, ActiveX has been a massive security hole since day one. I remember soon after ActiveX was announced, some professor using it to shut your computer down. If that doesn't sound like a big deal, it was since he could have done anything, but shutting the system down was the least damaging action he could think of that still drove home the point that it was a major problem. So MS introduced signing. Oops! That didn't stop folks from futher exploits. So they put in some extra dialog box confirmations. Oops! The dialog boxes were silently bypassed.
Saying that MSIE was (is) the top of the heap is easy. But to say that MSIE is the top of the heap in security? What? Using the grandparent's metaphor for safe sex...
Netscape crashes were like being with a premature ejaculator. "Hey asshole! I wasn't even close to done yet!"
MSIE on the other hand was a great lover. And then you found out later that you have chlamydia (spyware), ghonorrea (viruses), and syphilis (worms).
And that's not even covering when your lover squats over you and takes a dump all over you without even asking first (popups). Sure it won't kill you, but do you really need a few years of this to realize that most people don't like it? Why would anyone continue to torment their partner if they actually believed they would leave them? Better make sure they are otherwise dependent upon you.
The only reasons I can see most people putting up with it are battered spouse syndrome and/or ignorance that there are alternative choices available. Hmmm... Sounds like a typical MSIE user to me.
Actually, the larger, heavier particles get scrubbed. The smallest particles -- incidentally the most dangerous to health -- are the ones that get past the scrubbers and into the outside air.
Ah yes. I had forgotten about Sellafield. Then again, I did qualify my statement.
"Today's reactors (and those for at least the last..oh...thirty years) do not mix their reactor coolant water with the water used for the steam turbine."
Sellafield is going on fifty years old. It's a true first generation nuclear plant. Perhaps I am also too US-centric. There's no way the NRC would allow anything close to Sellafield. It was the NRC guidelines that I was using for reference.
You mean This guy? Hmmm... He supports nuclear because of all of the stable, mass power production methods out there, it produces the least amount of air, water, and PCB pollution without requiring land area equivalent to Connecticut and Delaware (like solar). He supports renewable resources and working with the logging industry to plant enough trees to replace the ones lost. He acknowledges that with over six billion people on the planet, there's an argument for the higher yields from genetically modified crops.
Personally I prefer organic foods and I don't eat much red meat (much less meat overall in fact than I used to), but he has an argument. This also isn't to say that I like companies like Monsanto.
But an industry shill? C'mon. Someone disagreeing with you doesn't automatically make you an industry shill. Oh wait. This is Greepeace we're talking about. I guess it does. *sigh*
...putting several times as much radiation into the atmosphere as nuclear plants.
While true, it's worth noting that both levels are far below toxic levels for radioactivity.
And coal plants don't belch out poisonous fumes at random. They do have scrubbers that catch 99% of the particals. I'm not saying they're clean. Far from it. But let's keep things rational here. (I know I get heated about this. Just trying to do my part to keep the debate open even though I strongly agree with you.)
In IFR/AFR reactor models, you don't need to separate out the plutonium. In fact, all the actinides can be separated from the elements lower on the periodic table fairly easily. It's only when you are striving for plutonium purity that those gross inefficiencies comes into play. In addition, IFR/AFR designs include the reprocessing facilities on-site. No outside transport necessary.
Yes sodium requires special handling and processes. Guess what? So does nuclear material. Guess what? So does any large-scale power production.
As for high-level, long halflife wastes, guess what long halflife means? Lower decay rate. Know one of the reasons why weapons-grade plutonium with the long halflife is so special? Because it decays slow enough enough that people can handle it without dying.
Point of comparison between weapons-grade plutonium and...oh I don't know...arsenic. Halflifes: Pu-239 has 14,000 years while As is infinite. Arsenic is harder to clean up. Arsenic is deadly in many delivery methods while Pu-239 is only really dangerous if inhaled since alpha particle decay can be stopped by a piece of paper. So why don't we try to stop all arsenic production? Why don't we push to halt its use in all capacities? Oh well. I guess Ralph Nader was wrong when he affirmed (pulled out of his ass?) that Plutonium "is the most toxic substance known to man."
Oh yeah...proliferation. How many nuclear countries are there now? How many are really going to be held back because the US isn't using fast reactors? I can see Somalia saying it now: "Well since the US is using breeder reactors for their power generation now, we should start a nuclear weapons program." Please.
News flash: No country (NO COUNTRY!) has ever used spent nuclear fuel as a basis for a nuclear weapons program. In over fifty years in a dozen nuclear countries, no one has seen fit to do it. Doesn't that speak volumes? Bottom line: it's easier to make a bomb from mined uranium ore than it is to make one with spent fuel.
When some thing has a very long halflife, that means its decay rate is much slower. "Lower decay rate" usually equates to "less dangerous." This is a simplification of course -- different isotopes will have different decay properties and may be any combination of alpha, beta, and gamma radiation -- but good enough to counter the FUD that somehow this stuff will kill you if you come within a mile of it for the next ten thousand years.
As for the "waste," current designs only allow for about 2% of the potential energy to be used. Enrichment could entend the life of this spent fuel dramatically as well as reduce the amount of real waste, but legislation and "proliferation" worries stopped all such activities for power generation in the US back in the late 70s. I put "proliferation" in quotes because unlike in the late 70s, fundamental nuclear "secrets" aren't really secrets anymore. Except for a few nations on UN watch lists, countries that want nuclear materials can get nuclear materials.
This is of course coupled with the fact that even though enrichment methods have been developed that do not generate high concentrations of weapons-grade plutonium -- basically too "hot" for common usage and much more likely to produce a fizzle bomb rather than a fission bomb -- these advances have been conveniently ignored by anti-"nuke" organizations. (I'll skip the extended commentary about how many such organizations can't tell the difference between the power and the weapons industries.)
As for transportation, let's have a look at France -- a country with over 70% of all of its power from nuclear. Nuclear material is transported on their roads on a fairly regular basis. This has been the case for years. France has also had to deal with terrorist attacks within its borders for a long time. That said, will someone please produce examples of nuclear material getting hijacked, co-opted, attacked, accidentally dropped, etc.? I'd really love to hear about it.
As for water being more radioactive after removal, umm... Source? Today's reactors (and those for at least the last..oh...thirty years) do not mix their reactor coolant water with the water used for the steam turbine. Now then, I'm not saying that the heat exchangers are 100% effective. What I am saying is that if the water were to give off even five mrems over background radiation per year -- about 250 mrems per year is common in the US with multiples of that every time you get on a plane -- I would be incredibly surprised.
The waters outside of Diablo Canyon for example are indeed warmer than the surrounding areas. They are not more radioactive though. And if you mean by "disrupting" that organisms that are usually found in the warmer, southern waters can be found, you'd be right. But rather than simply asserting that human influence is automatically a bad thing, please cite reasons why a particular case has resulted in harm rather than just very localized change. Hell, if we took Diablo Canyon offline, the organisms in the area would die out as the water cooled suddenly. Better?
As for the incendiary "'hot particles' of Plutonium/Uranium frequently leak out into the environment due to rusting equipment," I'm afraid I have to call bullshit. Is the nuclear industry perfect? Hell no! But this is totally uncalled for. Current regulations call for investigations when detected levels are at 10 mrems. Even if levels were at ten times allowed levels for a nuclear facility, and every employee on the premises were in on the conspiracy to cover it up, commonly accepted wisdom is that it would take 10 rems (10,000 millirems) to even enter danger levels for humans.
10 mrems still too much? Point of reference folks: you get body irradiated with about 20 mrems from the radioactive potassium isotopes in your own blood each and every year of your life. Everyone. Every year.
And plane crashes!?! The reactor is not in danger. Nuclear reactors in the western world are similar in construction (steel-reinforce
On the contrary, I think I got the point. I just wasn't clear on what I meant.
First off, I strongly disagree with your position that layout should not ever be done in pixels. What is a percentage if not a percentage of a pixel measurement? Monitors display in pixels. That's our baseline. I was speaking of pixels in the same way that a low-level programmer might speak of gotos. When working in C, gotos should generally be avoided. In assembly however, gotos are everywhere; They are a necessity to get anything done.
When I say someone should code to a particular resolution, I don't mean that people should make pages that only look good in that resolution. What I mean by coding to 800x600 is that I am willing to give a scrollbar to people at 640x480, but the layout should expand to use the available area in higher resolutions.
I also strongly disagree with your position that "everything else should be sized to a percentage of the viewing area." If someone has their browser at 800 pixels wide and you set a side navbar to be 30% of the total (240 pixels wide), this is reasonable for most nav text and info. But if another user has a browser that is set to 1024 pixels wide or more, that navbar starts taking up too much real estate in my opinion. It would be better if the main content area were to expand rather than the navigation bar. Not that I'm saying that you should set pixel values in your CSS mind you. Here is a case where most of the time, a width in em units would be better. That way, differences in user font sizes can be accomodated. Sometimes it's easy, but not always. If it was always easy, 99% of all web pages would be done like this. Unfortunately in the real world, some designs simply aren't that easy.
Take a look at one of my sites. Are you honestly saying that the main nav should be a percentage of the total? Take a look at one of the articles. Aren't you glad that when you expand/contract the browser, the main content is affected much more than the width of the nav?
And as a sidenote (not directed at the parent), idiots with their monitors set to 640 (or 800) because they "can't read the little text" are idiots and should be smacked on the head. Methods exist to make font sizes larger without having a screen with 1/4-inch-wide pixels or the infernal fuzzy-LCD effect encountered when running a flat panel at a non-native resolution. Stupid clueless users. Of course, web "designers" who specify "10px" as the height of their text should be shot for making this problem worse, as well as whomever is responsible for MSIE not being able to scale this text when requested, which comprises the majority of commercial websites.
I'm certainly glad that vitrol wasn't directed at me. I do take issue with you characterization of "idiots." People are free to browse the web as they please. It is our responsibility as webmonkeys to get our message out, not for the "idiots" to conform to us. You are obviously a young, healthy person who does not know what it is like to have horrible eyesight due to genetics, accidents, or simply old age. I myself use a 19" monitor at 1600x1200. I've also seen people with 21" monitors who use 640x480, and I do not begrudge them. Many of these folks did so not from ignorance or idiocy but rather from a standpoint of comfort.
I'm not saying you have to cater to these folks and make sure every design no matter the intended audience or extra time needed fits for absolutely everyone. In fact, if you want to code to maximized 1600x1200 resolutions, so be it. I code to a minimum of 800x600 and get an estimated >95% of desktop users. However, it is not right or justified to call them idiots simply because you would find it unreasonable or uncomfortable to do yourself. I don't mean to come down so hard, but I've had more than a few relatives who have had vision problems. It struck a nerve.
As for pixel sizes for fonts, that's not a simple issu
30% of what? The div element? The browser window? What units are those in? Oh yeah! PIXELS. Should a sidebar grow with a browser resizing? Not necessarily. Most of the time, you want the main content area to grow while the sidebars stay the same. However, when the user increases their font display size, you would want that sidebar to expand wide enough to accomodate that larger content. Thus we use the em. What is an em? The width of the letter 'm' in the current font. How is that width measured? PIXELS.
Everything in web design ultimately comes down to pixels. As long as monitors display with pixels, that's what we work with. Em, %, etc. are all just alternate forms of specifying a pixel width.
Okay, we both seem to be speaking English, but we're not communicating. I never said that layout should not be fluid. I wholeheartedly agree that layout should be fluid. And I know what ems are. I used them extensively on my main site.
However, the fact remains that layouts for screen presentation are done in pixels. Period. What is an em? The width of the letter em in the current font. What units are that width measured in? Not inches. Not percentages. Pixels. When you ask for a percentage of a screen, you aren't asking for a percentage of a 17" monitor. You are asking for a percentage of the page real estate. That page or portion of a page is so many pixels wide by so many pixels high. Pixels.
Now then, as for continuous tone images, what happens when you scale up a JPEG? It gets pixelated. Can a photograph be adequately represented in a vector format? Sure, but it would require so much information (read: huge file size) that its drawbacks for use on the web would far outweigh its advantages over formats such as JPEG. JPEGs on the other hand are perfectly suited to photographs -- aka continuous tone images -- but as a raster format cannot scale seamlessly like a vector graphic.
And when you are in front of a Mac OS 9 box, what do you do then? I still come across my fair share these days. What about public library computers that don't have front-facing USB ports?
Mindterm Lite comes in much smaller than the full version. Just download the source code from their site a build with the "lite" target. Remember, it doesn't need to have all of the bells and whistles of a standalone SSH client. All you need are the portion(s), the cipher(s), and the mode(s) that are necessary to talk to that one server.
Difference being that (a) the person who owns that computer would have to be okay with you downloading programs on their system, (b) that it's a Windows box that hasn't been locked down or that you are an administrator on, (c) that it isn't a Mac OS 9 box, etc.
I can access my server from public libraries if need be. Public libraries on the whole aren't too keen about installing random (to them) pieces of software on their computers. I haven't yet come across a library computer that didn't have Java though, but maybe I've just been lucky on my road trips.
As far as ease, what could be easier than:
1. Open IE 2. Address: your server 3. Enjoy
I guarantee you that the Java applet is a smaller download than putty. And when you're done, nothing to clean up off the machine you are using.
I have nothing against putty. I use it myself all of the time, but it's not solving the same problem I'm talking about.
First of all, it wasn't Caldera, it was Digital Research. Caldera simply bought the assets later. Second, it was malicious and intentional anti-competitive behavior by Microsoft. Have you read the court filings? Obviously not, or you would have understood the scope of what was done.
As far as "one case of bad press," one case of bad press about silicon breast implants brought Westinghouse (a huge company) to its knees on very questionable scientific grounds. In the Westinghouse case, it was fear, hysteria, and scapegoating. In the case of Microsoft and Digital Research, it was intentional corporate sabotage. It was perfectly reasonable to blame Microsoft, and competition had nothing to do with it. If competition was the issue, DR DOS would have wiped the floor with MS DOS in the marketplace. The same with Novell DOS.
Slashdot Mirror
Many wireless keyboards come with a fully functional PS/2 (or USB) base. Whether the keyboard is present or not, the simple presence of the base is sufficient to get past the BIOS.
I picked up one from CompUSA a few years ago for about $20. The keyboard has since died, but the base still works fine for my server. Remember, the keyboard quality doesn't matter here. Who cares if the wireless has a range of two feet if you don't want it for its wireless abilities?
IR has the advantage of allowing keyboard access when you want it too. Or, if you absolutely don't want it, duct tape on the photoreceptor works wonders.
What is a desktop icon if not just another form of link. What makes one link more special than another?
If XHTML is used for presentation, CSS is used for styling, DOM is used for the model, and scripting is used for logic, I don't see the problem. I thought you were complaining that there were too many technologies. Now it seems you are complaining that there are too few. From what you describe, it sounds like you would prefer a presentation and styling framework for web pages and a completely independent and different framework that does the same thing for applications only it adds logic and a data model. Does that make sense to you?
If you want to simplify, just use XHTML and CSS. Done. There's your online document. Simple as can be. With standards.
Want some dynamism? Want interaction? Add in scripting and voila! You have entered into the world of applications. For what is an application if not a way to receive, process, and send information? What it tells us is that it doesn't have to be either a web document or an application, 1 or 0, black or white. You can already make a web application that is functionally indistiguishable from most native applications. You can also make a hybrid model which is really what most authoring and reporting tools are after all.
Okay, first off, pointing to one particular page which isn't even standards compliant does not improve your argument.
Second, 100K easily fits into CPU cache let alone causing an issue for hundreds of megabytes of main memory. (And no, I don't think that's how CPU cache is effectively used. I just used it as a point of reference.)
Third, it compresses down to less than 20K using standard gzip compression. This equates to three seconds of download time on a 56Kbps modem connecting at 52Kbps. So yes, it could be more efficient, but come on.
Let's take a standards-compliant site like CSS Zen Garden or GeekSpeak.org. When someone actually bothers to reference the standards, you end up with a site with comparatively little markup. Both sites are less than 20K of markup and easily compress to less than 10K. Both are static pages, yes. But then again, so was your Spiegel reference.
With standards. Both are static pages, yes. But then again, so was your Spiegel reference.
What bloat do you see on those pages? How complex is the markup? How well do they stand up with accessibility? (Answer: very well) Both referenced sites are smaller than Spiegel's, but then Spiegel's is much older and established. Same story as with Amazon and eBay, inertia can be the biggest enemy no matter what direction you choose.
1. Consolidation of existing standards? Almost all new specs are XML-based and build upon existing technologies. As for cranking so many out, what does it matter? CSS2, DOM, SVG, XSL:FO, XSLT, etc. are all solutions to a particular problem set. That said, XSL:FO and CSS (for example) use many of the same attribute names. The markup languages all rely upon a common namespace spec. I don't see the problem. Can you be more specific?
1b. CSS has transparency. In CSS, the attribute is called "opacity". It's in CSS3. IE, Mozilla/Firefox, and Safari have all have support for transparency through proprietary extensions. Currently Safari 1.1+ and the newest versions of Mozilla/Firefox support the W3C directive as well.
Multicolor gradients in CSS is a bad idea in my humble opinion. Better to simply keep with CSS3's background image scaling and supply a SVG gradient. More flexible and doesn't mix concerns.
Embedding fonts has always been a political/economic issue rather than a technical one. Both IE and Netscape had competing dynamic font technology, but due to licensing fees demanded by the creators of the various fonts, most web developers decided to go without and use an image instead.
I agree about the CMYK and multi-column layout, but disagree about the printing. CSS is used for print output as well, but it's just that print isn't the only target. That support could definitely be much stronger though.
I personally think that the death of Java on the browser was a horrible thing. No, I don't bemoan the death of applets. I considered the lack of Java on the browser due to applets akin to throwing the baby out with the bathwater. Hmmm... Portable code, small size, large set of usable APIs... As long as the browser's main rendering engine was the presentation layer, the Java was the business logic, and some scripting language was the glue, I'd be happier than a pig in slop. I mean, be honest. What real portability problems have you seen in Java outside of the GUI? IBM's DirectDOM project held so much promise in this regard. Died in the womb though.
2. Am I to understand that you are blaming the technologies as being inadequate because Slashdot doesn't use them? eBay, Amazon, and Slashdot were all born before the DOM and CSS had become common. To retool each site would require a great deal of effort that would not necessarily make good business sense. Better for someone to start from scratch...like Gmail. Blogger has been adding some interesting editing choices as well in the last few months.
2b. Flash and Actionscript are faulty because of the technology or because elitist programmers prejudge it and thus don't make anything worthwhile. Me personally, I think that Flash movies can be great things: smaller than an MPEG or Quicktime video, easily scalable to multiple resolutions, easy to synchronize audio and video, and a full scripting engine to boot. I think you wrote this technology off far too quickly my friend. As far as "didn't catch on," how can it be in the vast majority of browsers, on every major browser platform, and every major desktop operating system and still be seen as not catching on? Because some people overuse Flash for ads and splash screens, this invalidates the whole technology? It was used for splash screens and ads precisely because it already caught on years ago.
2c. Web services are tied into the OS, yes. But on the server-side. There is no technical reason why this must be true on the client. In fact, since you never know if a Mac user will find your information useful or if a Linux user would want to purchase your wares, it makes sense to make sure that cross-client technologies like DOM and Javascript are used. The only trouble comes from absent-mindedly using IE-specific extensions.
As far as Longhorn is concerned, may I remind you that Longhorn will not be released in 2004. Or 2005. And maybe not 2006. And then you'll wait a few years for the desktops to catch up. The next Mac OS, Tiger
Although he failed to properly qualify it...
Open Source kills [Microsoft] jobs.
Which reminds me: we've been hearing for years from people on usenet and various mailing lists that HTML content was horrible, that their clients ended up with the raw markup which was unintelligible, and archiving of HTML email was prohibitively difficult. We've been hearing this for like what? Eight years?
The most vocal of this group have been the technological elite, right? These are the ones that continually browbeat newcomers about how their email/news client is ruining everything.
To those folks I ask this one simple question: Why didn't you write a text-based email/news client eight years ago that strips the tags or (simpler) detects when there is a plain-text MIME segment? End of problem on both ends.
Unfortunately, much of the push to move away from web applications is coming from programmers, not from real users.
The DOM is your example of incompatibility? Take IE 6 and compare it to the ECMAScript/JavaScript standard. Do the same with Firefox. Amazing. They both follow at least 99% of the spec.
You speak of not needed an HTML page 'in between' for the info. You're right. But I keep getting this strange feeling that in place of the HTML (or other markup), you would have layout and functionality embedded in some programming language. No thank you. I remember what that was like, and I have no intention of going back to those days. I'd much rather specify my UI in a semantic markup and style it with CSS or something like it.
I'm sorry... I took a moment to finish laughing at your "wasting gazillion of Terrabytes" comment. A properly configured web server compresses the HTML that comes out of it. And even if it didn't, we're still talking about numbers so small that even modem users don't care much. It's the graphics, movies, and audio clips that "waste" bandwidth, not the markup. The great thing about site-wide JavaScript files and CSS stylesheets is that they only need to be downloaded once.
As for focusing on "sending and communicating the truely wanted data as direct, speedy and interactive as possible - without any unnecessary wrappers," I encourage you to lookup up techniques such as background page loads and their ilk. In fact, if XML were to bug you too much because of the perceived bloat (see note about compressing markup earlier), you could always just wrap a tab-delimited file in a single tag and split the results after the file comes down. It could suck if/when you want to add new fields, but you could do it. And there you go, no bloat. Bottom line: client and server can talk directly. People simply haven't yet while older browsers were still around to gum up the works.
No, but it also wasn't meant for just documents and news. It was for presenting information. Whether that information is part of a news page or part of an Amazon query result, why should we or the markup care?
Oke, let's form some rebuttals here:
1. Browsers: What would be more perfect to you? I'm not saying you are wrong, but I doubt you would come up with a radical new approach that wouldn't immediately turn people off. Click to go to a new page based on content context. Click "back" to go back. URL autocompletion. Tabbed browsing. Mouse gestures. What exactly is so deficient, and more importantly, what is your proposed solution?
As for CSS, it wasn't meant to generate primitive shapes. That's what SVG was meant for. What's the alternative? Primitive shapes in CSS like triangles, circles, elipses, pentagons, hexagons, dodecahedrons, etc.? What is a basic shape to you? I guarantee that as soon as you decide, someone else will pop out of the woodwork and proclaim that it's not enough. Personally, I think the existing spec can handle quite a lot as it is.
Postscript is primarily a print format. CSS is not just for print publishing. For example, are there postscript directives specifically for text (aural) readers? Does postscript keep the content separate from the presentation or are they inextricably tied together? Apples and oranges in my opinion.
2. Web Applications: Going beyond the page metaphor isn't hard with the DOM. As for removing the browser, Microsoft has been doing this for years with the componentization of their rendering widget. The Mozilla group have a toolkit based upon XUL and XPCOM. Multiple applications have taken Mozilla's rendering widget and made non-browser apps. Flash is showing great promise with their ActionScript and XML handling features (based on DOM by the way). The fact remains that application development is easier on a browser than just about anywhere else.
The issue I see isn't that Macromedia needs to produce a decent programming tool. The power of web applications is that the technologies are already used and practiced by hundreds of web developers around the world. This is the strength of Apple's Dashboard work. I see the issue more as one where developers at large haven't moved beyond the page metaphor, not that the technology hasn't.
Those of you who use Gmail can relate to me here. I very much believe that they're pushing past the page metaphor in impressive ways like expanding conversation threads without refreshing the browser window, checking spelling seamlessly, etc. It's to the credit of the Gmail team (among others) that they realized that the number of browsers that can functionally handle advanced scripting and use a standard set of APIs has finally hit critical mass.
As for ditching the browser, here is an interface that everyone knows and understands today. Here is a piece of software so ubiquitous, that it is more common than an email client on desktops and kiosks. Now you're saying we should drop this advantage and go backward to a time of greater balkanization because what we have doesn't solve even problem perfectly? That's the solution: dump it and get something new from scratch? If I click on a link and it opens a new browser window without the default navigation buttons or taskbar, how is this worse? How is this distinguishable to the general public from a "real" application on their computer? How would your ideal framework be fundamentally different from the same window only launched from a desktop icon instead of a hyperlink?
Yes, I can acknowledge things like local filesystem access. This is a need for a framework outside of the browser. Except...well...Mozilla, Microsoft, Macromedia et al have already solved it. Pick your flavor. They all work. In fact, they all work in much the same way: some markup, some scripting (usually accessing the DOM or a thin layer on top of it), and some external styling. However, this doesn't invalidate all browser application development. It just means that there is no single silver bullet.
I agree with you and others that browsers won't go away. In fact, I sincerely hope they don't.
So if an alternate browser is to render exactly like IE, I must ask, "Which version of IE?"
I don't know about that. I was "around" in the mid-90s. Yes, Netscape had its share of exploits (mostly Javascript), but Netscape's main faults were crashing and lack of features (like good CSS support).
On the other hand, MSIE has had more than its share of scripting exploits. In addition, ActiveX has been a massive security hole since day one. I remember soon after ActiveX was announced, some professor using it to shut your computer down. If that doesn't sound like a big deal, it was since he could have done anything, but shutting the system down was the least damaging action he could think of that still drove home the point that it was a major problem. So MS introduced signing. Oops! That didn't stop folks from futher exploits. So they put in some extra dialog box confirmations. Oops! The dialog boxes were silently bypassed.
Saying that MSIE was (is) the top of the heap is easy. But to say that MSIE is the top of the heap in security? What? Using the grandparent's metaphor for safe sex...
Netscape crashes were like being with a premature ejaculator. "Hey asshole! I wasn't even close to done yet!"
MSIE on the other hand was a great lover. And then you found out later that you have chlamydia (spyware), ghonorrea (viruses), and syphilis (worms).
And that's not even covering when your lover squats over you and takes a dump all over you without even asking first (popups). Sure it won't kill you, but do you really need a few years of this to realize that most people don't like it? Why would anyone continue to torment their partner if they actually believed they would leave them? Better make sure they are otherwise dependent upon you.
The only reasons I can see most people putting up with it are battered spouse syndrome and/or ignorance that there are alternative choices available. Hmmm... Sounds like a typical MSIE user to me.
I still wouldn't call it random.
Actually, the larger, heavier particles get scrubbed. The smallest particles -- incidentally the most dangerous to health -- are the ones that get past the scrubbers and into the outside air.
Ah yes. I had forgotten about Sellafield. Then again, I did qualify my statement.
"Today's reactors (and those for at least the last..oh...thirty years) do not mix their reactor coolant water with the water used for the steam turbine."
Sellafield is going on fifty years old. It's a true first generation nuclear plant. Perhaps I am also too US-centric. There's no way the NRC would allow anything close to Sellafield. It was the NRC guidelines that I was using for reference.
My apologies.
You mean This guy? Hmmm... He supports nuclear because of all of the stable, mass power production methods out there, it produces the least amount of air, water, and PCB pollution without requiring land area equivalent to Connecticut and Delaware (like solar). He supports renewable resources and working with the logging industry to plant enough trees to replace the ones lost. He acknowledges that with over six billion people on the planet, there's an argument for the higher yields from genetically modified crops.
Personally I prefer organic foods and I don't eat much red meat (much less meat overall in fact than I used to), but he has an argument. This also isn't to say that I like companies like Monsanto.
But an industry shill? C'mon. Someone disagreeing with you doesn't automatically make you an industry shill. Oh wait. This is Greepeace we're talking about. I guess it does. *sigh*
And coal plants don't belch out poisonous fumes at random. They do have scrubbers that catch 99% of the particals. I'm not saying they're clean. Far from it. But let's keep things rational here. (I know I get heated about this. Just trying to do my part to keep the debate open even though I strongly agree with you.)
In IFR/AFR reactor models, you don't need to separate out the plutonium. In fact, all the actinides can be separated from the elements lower on the periodic table fairly easily. It's only when you are striving for plutonium purity that those gross inefficiencies comes into play. In addition, IFR/AFR designs include the reprocessing facilities on-site. No outside transport necessary.
Yes sodium requires special handling and processes. Guess what? So does nuclear material. Guess what? So does any large-scale power production.
As for high-level, long halflife wastes, guess what long halflife means? Lower decay rate. Know one of the reasons why weapons-grade plutonium with the long halflife is so special? Because it decays slow enough enough that people can handle it without dying.
Point of comparison between weapons-grade plutonium and...oh I don't know...arsenic. Halflifes: Pu-239 has 14,000 years while As is infinite. Arsenic is harder to clean up. Arsenic is deadly in many delivery methods while Pu-239 is only really dangerous if inhaled since alpha particle decay can be stopped by a piece of paper. So why don't we try to stop all arsenic production? Why don't we push to halt its use in all capacities? Oh well. I guess Ralph Nader was wrong when he affirmed (pulled out of his ass?) that Plutonium "is the most toxic substance known to man."
Oh yeah...proliferation. How many nuclear countries are there now? How many are really going to be held back because the US isn't using fast reactors? I can see Somalia saying it now: "Well since the US is using breeder reactors for their power generation now, we should start a nuclear weapons program." Please.
News flash: No country (NO COUNTRY!) has ever used spent nuclear fuel as a basis for a nuclear weapons program. In over fifty years in a dozen nuclear countries, no one has seen fit to do it. Doesn't that speak volumes? Bottom line: it's easier to make a bomb from mined uranium ore than it is to make one with spent fuel.
When some thing has a very long halflife, that means its decay rate is much slower. "Lower decay rate" usually equates to "less dangerous." This is a simplification of course -- different isotopes will have different decay properties and may be any combination of alpha, beta, and gamma radiation -- but good enough to counter the FUD that somehow this stuff will kill you if you come within a mile of it for the next ten thousand years.
As for the "waste," current designs only allow for about 2% of the potential energy to be used. Enrichment could entend the life of this spent fuel dramatically as well as reduce the amount of real waste, but legislation and "proliferation" worries stopped all such activities for power generation in the US back in the late 70s. I put "proliferation" in quotes because unlike in the late 70s, fundamental nuclear "secrets" aren't really secrets anymore. Except for a few nations on UN watch lists, countries that want nuclear materials can get nuclear materials.
This is of course coupled with the fact that even though enrichment methods have been developed that do not generate high concentrations of weapons-grade plutonium -- basically too "hot" for common usage and much more likely to produce a fizzle bomb rather than a fission bomb -- these advances have been conveniently ignored by anti-"nuke" organizations. (I'll skip the extended commentary about how many such organizations can't tell the difference between the power and the weapons industries.)
As for transportation, let's have a look at France -- a country with over 70% of all of its power from nuclear. Nuclear material is transported on their roads on a fairly regular basis. This has been the case for years. France has also had to deal with terrorist attacks within its borders for a long time. That said, will someone please produce examples of nuclear material getting hijacked, co-opted, attacked, accidentally dropped, etc.? I'd really love to hear about it.
As for water being more radioactive after removal, umm... Source? Today's reactors (and those for at least the last..oh...thirty years) do not mix their reactor coolant water with the water used for the steam turbine. Now then, I'm not saying that the heat exchangers are 100% effective. What I am saying is that if the water were to give off even five mrems over background radiation per year -- about 250 mrems per year is common in the US with multiples of that every time you get on a plane -- I would be incredibly surprised.
The waters outside of Diablo Canyon for example are indeed warmer than the surrounding areas. They are not more radioactive though. And if you mean by "disrupting" that organisms that are usually found in the warmer, southern waters can be found, you'd be right. But rather than simply asserting that human influence is automatically a bad thing, please cite reasons why a particular case has resulted in harm rather than just very localized change. Hell, if we took Diablo Canyon offline, the organisms in the area would die out as the water cooled suddenly. Better?
As for the incendiary "'hot particles' of Plutonium/Uranium frequently leak out into the environment due to rusting equipment," I'm afraid I have to call bullshit. Is the nuclear industry perfect? Hell no! But this is totally uncalled for. Current regulations call for investigations when detected levels are at 10 mrems. Even if levels were at ten times allowed levels for a nuclear facility, and every employee on the premises were in on the conspiracy to cover it up, commonly accepted wisdom is that it would take 10 rems (10,000 millirems) to even enter danger levels for humans.
10 mrems still too much? Point of reference folks: you get body irradiated with about 20 mrems from the radioactive potassium isotopes in your own blood each and every year of your life. Everyone. Every year.
And plane crashes!?! The reactor is not in danger. Nuclear reactors in the western world are similar in construction (steel-reinforce
First off, I strongly disagree with your position that layout should not ever be done in pixels. What is a percentage if not a percentage of a pixel measurement? Monitors display in pixels. That's our baseline. I was speaking of pixels in the same way that a low-level programmer might speak of gotos. When working in C, gotos should generally be avoided. In assembly however, gotos are everywhere; They are a necessity to get anything done.
When I say someone should code to a particular resolution, I don't mean that people should make pages that only look good in that resolution. What I mean by coding to 800x600 is that I am willing to give a scrollbar to people at 640x480, but the layout should expand to use the available area in higher resolutions.
I also strongly disagree with your position that "everything else should be sized to a percentage of the viewing area." If someone has their browser at 800 pixels wide and you set a side navbar to be 30% of the total (240 pixels wide), this is reasonable for most nav text and info. But if another user has a browser that is set to 1024 pixels wide or more, that navbar starts taking up too much real estate in my opinion. It would be better if the main content area were to expand rather than the navigation bar. Not that I'm saying that you should set pixel values in your CSS mind you. Here is a case where most of the time, a width in em units would be better. That way, differences in user font sizes can be accomodated. Sometimes it's easy, but not always. If it was always easy, 99% of all web pages would be done like this. Unfortunately in the real world, some designs simply aren't that easy.
Take a look at one of my sites. Are you honestly saying that the main nav should be a percentage of the total? Take a look at one of the articles. Aren't you glad that when you expand/contract the browser, the main content is affected much more than the width of the nav?
I'm certainly glad that vitrol wasn't directed at me. I do take issue with you characterization of "idiots." People are free to browse the web as they please. It is our responsibility as webmonkeys to get our message out, not for the "idiots" to conform to us. You are obviously a young, healthy person who does not know what it is like to have horrible eyesight due to genetics, accidents, or simply old age. I myself use a 19" monitor at 1600x1200. I've also seen people with 21" monitors who use 640x480, and I do not begrudge them. Many of these folks did so not from ignorance or idiocy but rather from a standpoint of comfort.
I'm not saying you have to cater to these folks and make sure every design no matter the intended audience or extra time needed fits for absolutely everyone. In fact, if you want to code to maximized 1600x1200 resolutions, so be it. I code to a minimum of 800x600 and get an estimated >95% of desktop users. However, it is not right or justified to call them idiots simply because you would find it unreasonable or uncomfortable to do yourself. I don't mean to come down so hard, but I've had more than a few relatives who have had vision problems. It struck a nerve.
As for pixel sizes for fonts, that's not a simple issu
Everything in web design ultimately comes down to pixels. As long as monitors display with pixels, that's what we work with. Em, %, etc. are all just alternate forms of specifying a pixel width.
Duh.
Okay, we both seem to be speaking English, but we're not communicating. I never said that layout should not be fluid. I wholeheartedly agree that layout should be fluid. And I know what ems are. I used them extensively on my main site.
However, the fact remains that layouts for screen presentation are done in pixels. Period. What is an em? The width of the letter em in the current font. What units are that width measured in? Not inches. Not percentages. Pixels. When you ask for a percentage of a screen, you aren't asking for a percentage of a 17" monitor. You are asking for a percentage of the page real estate. That page or portion of a page is so many pixels wide by so many pixels high. Pixels.
Now then, as for continuous tone images, what happens when you scale up a JPEG? It gets pixelated. Can a photograph be adequately represented in a vector format? Sure, but it would require so much information (read: huge file size) that its drawbacks for use on the web would far outweigh its advantages over formats such as JPEG. JPEGs on the other hand are perfectly suited to photographs -- aka continuous tone images -- but as a raster format cannot scale seamlessly like a vector graphic.
Am I clearer now?
And when you are in front of a Mac OS 9 box, what do you do then? I still come across my fair share these days. What about public library computers that don't have front-facing USB ports?
You'll never know until you try will you?
Mindterm Lite comes in much smaller than the full version. Just download the source code from their site a build with the "lite" target. Remember, it doesn't need to have all of the bells and whistles of a standalone SSH client. All you need are the portion(s), the cipher(s), and the mode(s) that are necessary to talk to that one server.
Difference being that (a) the person who owns that computer would have to be okay with you downloading programs on their system, (b) that it's a Windows box that hasn't been locked down or that you are an administrator on, (c) that it isn't a Mac OS 9 box, etc.
I can access my server from public libraries if need be. Public libraries on the whole aren't too keen about installing random (to them) pieces of software on their computers. I haven't yet come across a library computer that didn't have Java though, but maybe I've just been lucky on my road trips.
As far as ease, what could be easier than:
1. Open IE
2. Address: your server
3. Enjoy
I guarantee you that the Java applet is a smaller download than putty. And when you're done, nothing to clean up off the machine you are using.
I have nothing against putty. I use it myself all of the time, but it's not solving the same problem I'm talking about.
First of all, it wasn't Caldera, it was Digital Research. Caldera simply bought the assets later. Second, it was malicious and intentional anti-competitive behavior by Microsoft. Have you read the court filings? Obviously not, or you would have understood the scope of what was done.
As far as "one case of bad press," one case of bad press about silicon breast implants brought Westinghouse (a huge company) to its knees on very questionable scientific grounds. In the Westinghouse case, it was fear, hysteria, and scapegoating. In the case of Microsoft and Digital Research, it was intentional corporate sabotage. It was perfectly reasonable to blame Microsoft, and competition had nothing to do with it. If competition was the issue, DR DOS would have wiped the floor with MS DOS in the marketplace. The same with Novell DOS.