Maybe I didn't make it clear enough. Says right in my comment: "Users could put a cap on the maximum amount they could pay/transfer in any one month." Especially if an exemption was made for the cableco's own servers, I think that would take care of your problem. You might accidentally lose connectivity after ten days if you download too much, but you'd be able to check your email no matter what, and next month you'd be a bit more conscientious in your use.
Most people don't want IM. Most people don't want email. Most people don't want websites. Most people don't even want phone; it's better if they're inaccessible, so they can get work done without having to deal with the phone.
Of course people don't use the high bandwidth because they aren't interested. The technology isn't cheap and accessible enough to use it. If videoconferencing really worked as well as face-to-face meetings, do you think anybody would fly out from Boston to go to a meeting in LA?
No one knows how to use this extra bandwidth yet, that's just the point. We need to give room to try out these technologies. It's the chicken and the egg: AT&T won't make bandwidth available because people don't use it, and people aren't developing applications for the high bandwidth because nobody has it. AT&T should realize this and make the first move. Later, they'll realize they made the right choice.
No. A system that works is not a system where companies can exploit users who guess too low or too high about their usage habits; a system that works is one where consumers pay exactly for what they use, and nothing more.
Suppose AT&T started offering lines for $10/mo, with bandwidth running for $5/Gb, incremented in bytes. (As usual, the numbers are bullshit.) A user who transferred 1 gigabyte of content a month would pay $15. A user who transferred 10 megabytes of content a month would pay $10.50. A user who transferred 10 gigabytes of content would pay $60. You wouldn't pay in advance, or buy "blocks of bytes", or anything stupid like that; you'd just pay for what you actually use. Users could put a cap on the maximum amount they could pay/transfer in any one month, but otherwise they could use as little or as much as they want.
Now personally, I don't like the idea of a system like that; like I said before, if bandwidth costs money, then high-bandwidth applications aren't going to take off. The optimal system is ubiquitous wireless. The next-best system is probably what I described above. Another alternative system is daily caps; i.e. instead of being able to download 1.5 mb/s, you can transfer 16 gigabytes a day, but you can do it as fast as your cable modem will technically allow; if it formerly took an hour to download an ISO, maybe now you can do it in twenty minutes; but download too many and that's your internet use for the day.
The current system of speed caps is pretty bad, but the only thing worse is tiered speed caps.
As I said we should do in my other post to this article.
Until that happens; bandwidth may not grow on trees, but there's way more of it out there than we know what to do with. Backbone providers don't charge for speed, they charge for data; AT&T pays not according to how fast, but to how much. Therefore, it only makes sense that users should be able to do the same.
I did the calculation in another post; I don't have the number with me now, but this point is, I have an effective usage cap consisting of some huge amount of data per month, assuming I'm on 24/7 using full speed connections; so why can't I use that as quickly as I want? If I want to download an ISO image in a minute, and then that's my only network usage for the day, why not?
It seems strange to me how many slashdotter seems to deeply distrust the free market (it must be Microsoft that did it...).
And it seems strange to me how many Slashdotters seem to deeply mistrust anything but the free market; there are many more anarcho-capitalists than anarcho-communists on this site, it seems, despite Microsoft.
Sure, people who know they need the bandwidth and can afford it will pay extra. The thing is, if it doesn't cost AT&T anything at all to provide the extra speed, and it doesn't, then charging different prices for different speeds is nothing less than exploitation. To be honest, bandwidth caps make much more sense than speed caps. 3942000 megabits per month is the most I can get from my cable modem... why can't I get it as fast as I wantT?
This just proves why we need ubiquitous wireless internet.
To all you who would say that there are health problems: Bah. There's already tons of wireless signals going through the air with radio and TV, and you don't see everyone getting cancer, do you?
TV, especially now that it's becoming digital, can easily be transferred over the Internet. Radio can easily be transferred over the Internet (look at Shoutcast). IPv6 insures that there are enough IP addresses that every person on the planet can have a subnet and we're nowhere near running out. So why not just make everything go over the Internet?
Take away all public TV wireless broadcasts, and all radio broadcasts. Then, in their place, start broadcasting wireless networks, everywhere. Completely for free. Radios are reworked to use IPv6 and pick up Internet signals; TVs the same. Support for 802.11g, or a newer protocol, is built into every single computer, TV, car; the list goes on.
There's another important impact if this happens: you're no longer paying for connectivity, so that money is freed up for other uses. People who are now paying $10/mo for NetZero, $23/mo for AOL, or $50/mo for AT&T Broadband now can use that money to pay for premium content. Micropayments can be instituted on a mass scale; most people would only end up spending about $10/mo anyway on micropayments, and power users who spend huge amounts of time on the Internet just pay more. People get the same speed no matter what.
I watch in vain as yet more people fail to understand the evils of tiered pricing.
Recently, Case Western University decided to equip thousands of computers with a 1gb/s fiber network. They didn't quite know what people would use the bandwidth for, but they wanted to find out.
Why am I bringing this up? Ordinary users will only pay AT&T the cheapest price possible for a broadband connection. Now, that's $45; soon, AT&T may introduce a $20-$25 package, and theoretically some people now paying the higher price would downgrade to that package.
But there's tons of high-bandwidth applications available that most people don't use yet. Imagine real-time videoconferencing with resolutions as good as a printer. Imagine downloading OS or application upgrades from the Net in seconds. Hell, who would need hard drives anymore; bandwidth would be faster! There's all sorts of things we haven't thought of yet. But as long as AT&T imposes artificial bandwidth caps, that won't happen.
As bad as tiered pricing are upstream caps. That means that two cable modem users can only communicate with each other at ISDN speeds. There goes any useful peer-to-peer connectivity applications. Don't you all remember back when you used Napster, you'd always sort downloads by modem type, and skip anything lower than a T1? Downloading from one of your fellow cable modem users would have taken 8 times as long as downloading from someone with a leased line - but we can't all have leased lines, can we?
Tiered pricing is fine if it's due to technical constraints. If cable lines in San Francisco and Boston, for example, are higher-quality than lines elsewhere, there would be nothing wrong with offering faster service. But AT&T cannot justify offering service slower than what the cable lines allow; doing that will do much to halt the pace of network innovation. Shame on all providers who offer anything less than network capacity, in both directions.
First off, let me say that I just tried downloading Mozilla 1.1 beta for Win32 on a 750 MHz Duron, and was surprised to find that everything worked in real-time. Then again, maybe I shouldn't be, given that my last experience was on BeOS on a 466 MHz Celeron.:D
Then again, Mozilla could be released as native widget versions. But then why would anyone use Galeon, K-Meleon, or Chimera. Aren't those native widget ports of Mozilla? Isn't that what you asked for: a default build of XUL with popular platforms having a native widget option? Where's the problem?
Chimera - good example. Chimera browser is part of Mozilla; it's website is chimera.mozdev.org . Chimera uses Aqua, for everything - scrollbars, checkboxes, etc. Therefore, there's no Galeon-like independent port for OS X, because who needs it? In other words, Moz team should do Chimera for Win32 and GTK, too. That's all I want.
So all UI code should be compiled eh? What if XUL were compiled? Would you still have objection to it? I ask because recent Mozilla builds (including 1.0) have a file called XUL.mfasl. To quote the release notes
I think that, on major platforms, Mozilla should render XUL code using native widget libraries instead of its custom libraries, like it does with Chimera on OS X. They should still use XUL, just abandon "Modern" and instead use Win32 or GTK. Not for speed, but for consistency. That's all.
try and confuse me with numbers all you want, all I know is that my KDE with Mosfet's Liquid engine looks far prettier than and Gnome app I've seen:)
It's nice... though I expect, during practical use, ThinIce is better. Ever used ThinIce, or its superior variant MoonIce? Best engine I've ever seen, mainly for it's speed and clean-ness. It's not the best looking, but I don't pick my widgets for art; I've got my desktop background, and transparent windows, for that.
seriously though, I think they do have both a GTK and a Qt port, I've just never bothered to get it to work. btw, from your numbers 42% use KDE and 35% use Gnome (with or without the other toolkit's apps), wouldn't it stand to reason that more people would want the Qt port, for their "native" as it were environment?
No. First, that leaves off the huge numbers of people who use a different environment; wmaker, enlightenment, blackbox, even fvwm. Second, building on that, gtk is the lowest common denominator. Let's say 50% of people have qt installed. Hell, let's say 80% of people have qt installed. Well, 100% of people have GTK installed. There should be a port for both, but the GTK one first.
It's a non-issue anyway; both the GTK and Qt teams should abandon work now and switch over to Fresco.:D
I personally use both Mozilla and Konqy. while Konq is prettier (better looking/better anti-aliased fonts is the biggest thing here) and plays better with the rest of the environment, Mozilla is just an all around better browser. why so many people seem to think that you have to use only one browser, anyway?
One browser should be flexible enough to handle all situations. Maybe you have two different shortcuts, one to open it in minimal-mode and one to open it in full-featured mode, but it should be able to handle all situations.
Now, what I'd love to see is a port of Konqy to Gnome2.:D But that'll never happen.
Good news... sawfish, available today, supports one-dimensional virtual desktops (i.e. you can have five in a line, but not four in a square), and is Gnome2 native. Maybe you've been using metacity?
Yes, KHTML is a great browser. And this just goes to show the stupidity of both the KDE and Gnome teams.
I think it's fair to say that over half of the code that goes into KDE and Gnome has absolutely nothing to do with GUIs. Sure, it'll be used in a GUI context, but the code itself is completely GUI independent. Like drag-and-drop, for example.
So, how come the KDE and Gnome teams don't just unite under a common desktop framework, and have the only separate thing be the Qt- or GTK-specific parts? It would improve development so much, make it easier for other desktops to be compatible with both, make it easier for application developers to write programs for both (they only need to use two widgets, not two desktops), and make Linux more consistent.
Ah, I hope that someday, freedesktop.org is complete...
Until then... I could just compile konqy as a standalone app with staticly-linked Qt and kde-libs, right?
Okay, I've been trolled. C'mon now. "A couple of seconds"? I'm writing this on a P2-300 Vaio laptop. If a menu took a single second to load, Mozilla would be usuable for me. I seriously doubt that you have used Mozilla in the last year. If you have, then you are just lying or trying to run it on a 486 with 16MB of RAM.
Last time I used Mozilla, it was last week; the 19-July build for BeOS. Compared to everything else in BeOS, it was damn slow; so slow that I routinely used NetPositive, with its horrible rendering engine, just to avoid loading Moz.
Optimize the preferences dialog algorithms, and XUL will seem faster.
Fair enough, except that my only complaint with the prefs, at least as compared to the rest of XUL, is that they routinely won't save. They're no slower than anything else, for me at least.
AbiWord supports Windows, Linux, FreeBSD, Mac OS X, and QNX. That's it.
So I guess my copy of AbiWord on BeOS was just a dream then? No, probably not, seeing that it's right here. It doesn't support Mac OS 9 because that's a dead OS.
Also, if you'll read my original post, I don't think XUL should be completely scrapped. I simply think that, on the more popular platforms, XUL should be eschewed in favor of native widgets. Use XUL for AmigaOS, Mac OS 9, and other dead OSes; use native widgets for Windows and GTK.
My point was that Galeon does less than Mozilla. In addition, I believe that a new XUL "theme" (for lack of a better word) could make Mozilla look exactly like Galeon with comparable speed.
I've used themes that have not a single button (simply a URL bar), yet they're slower than Galeon. When I dual-boot into Windows, to run IE, a web browser that does as much as Mozilla, IE runs circles around Moz. So, why?
Sounds very similar to the arguments you are making now.
I have a new slogan for XUL. It's "write once, run anywhere." Oh wait, that's someone else's slogan - Java! Do you think that we should all start programming in Java instead? I think that C is good, Objective C is better, and eventually even higher-level languages should be used. But I think, for the most part, they should always be compiled, not emulated. Clearly most other people agree with me; if write-once run-anywhere was so good, Windows would be written in Java right now.
How about twenty years ago when the X Windows System was first being proposed. Why on earth would anyone want a universal windowing system? It will be the death of innovation and speed.
Funny you should bring that up - I've been advocating the mass deployment of Berlin, now Fresco, for a while now. Because Fresco's much higher-level than X, and will therefore make xplatformability easier. But Fresco is written in C++, and when you run Fresco on your computer, you're running a machine language app. It would be absurd to write Fresco, or X, in Java; it would be insanely slow. Instead, they're written in C/C++; portable to multiple platforms, but fast.
research project after research project has demonstrated that productivity skyrockets after using a scripting language in place of a compiled language like C. These same real-world study documents also demonstrate no great speed increase in most (>90%) applications when C is used.
Productivity for what? I agree that most small apps should be written in some form of a scripting language, as Perl/Python (Parrot!) has become fast enough for most use. Especially for console apps; how great it is to have one console Jabber client that I can run on every platform (yes, it exists). But something like Mozilla is so huge that writing it in an emulated language won't work.
Remember Knuth's 80-20 rule? You did read Knuth's work right? 80% of running time is in 20% of the code. How much time do you think the UI is taking in processing time? Let's suppose for the moment that you're right, I'm wrong, and XUL is the source of all of the problems with speed in Mozilla. In most browsing sessions, I barely touch the menubar; most of my time is spent in the main browser area. If I'm not interacting with XUL most of the time, how can it be such a horrible timesink in real-world use.
I don't know about you, but it's rare that I can get Moz to accept keyboard shortcuts. For whatever reason, it fails to do so. Therefore, I often have to resort to the back and forward buttons. It shouldn't take upwards of 5 seconds to even select "back", as it did on Be. Maybe it's better on other platforms, but not on Be.
That said, I assert that you have not put a profiler on Mozilla and are talking out of your ass with regard to the XUL engine. You might say that the UI design is bad. You might say that some of the backend component calls could use some optimization, but when you say that XUL is too slow to comfortably use, you sound like a fool.
Whereas your insults make you sound more intelligent. I might say that XUL is bad from a philosophical standpoint. I think that all widgets should be consistent. That's why I like Fresco; finally, no more toolkits, everything is consistent, and themes are universal. That's why I hate skins, and why I generally resort to using mpg321 (GPLed clone of mpg123) to play audio, because I can't find a skin-free GTK player. In the case of xmms, I'll freely admit that skins don't make it any slower, and that most of the player is in GTK anyhow. But, in my opinion, the whole concept of a desktop that has ten different programs with ten completely different looks is beyond me. On win32 and GTK, Moz should use native widgets, not for the speed but for consistency.
If you want consistency of browser UI when using multiple operating systems (as I do), then use Modern. If you want something more akin to a native feel, use classic. If you absolutely want native widgets, use Galeon, K-Meleon, or Chimera. That's what these projects are there for!
That's the thing. Why do you want consistency of browser UI between multiple operating systems over consistency within an OS? It's the rare OS that isn't themable; why don't you just pick a look that you like, say Modern, set the entire OS to look like that, and have Moz use native widgets?
As a side note, XUL is rendered by Gecko. You can't say that one is slow while the other is fast. They are different limbs of the same beast.
For text, it's fine. For everything else, Gecko is slow. As pages are mostly text, the slowness of Gecko doesn't matter much; for XUL, you really notice it, especially because normally, widgets are faster than any other part of the UI (even when Gecko isn't a factor).
The reason that Mozilla developers can handle the large number of platforms that Mozilla runs on is because of XUL. The code is amazing in its cross-platform purity. Fix a mail client bug here and it's fixed everywhere. Fix a UI bug there and its fixed everywhere. Contrast this with fixing a UI bug in the Windows code and it must be fixed in Mac (OS 9- and OS 10+), X (Xlib, GTK+ and Qt ports), BeOS, OS/2, OpenVMS(!), Amiga, etc.
AbiWord is the same way, but it uses native widgets, and clicking an AbiWord menu works instantaneously, whereas clicking a Moz menu takes multiple seconds to load - it just doesn't feel clean.
I'm not saying that XUL didn't take a long time. I'm not saying that it saved a whole lot of development time until recently. What I am asserting is that all new bugfixes and enhancements can now happen much faster (and have been for the last year or so) than would be possible with native libraries and widgets. And it's not like Mozilla isn't modular and reusable; how do you think Galeon and K-Meleon were able to be released so quickly? They whipped up a barebones UI up on the infrastructure written by Mozilla developers. If you like Galeon, K-Meleon, and Chimera, it probably has more to do with liking barebones UIs than an inherent deficiency in Mozilla's UI. That said, if that's your preference, more power to you. Just don't shit on someone else's meal when your food comes from the same kitchen.
I suppose you like Word's UI then? Or would you rather use a less bloated word processor?
Honestly, I don't know a single person who truly prefers complex interfaces to simple ones.
What the Mozilla developers have done is akin to shunning assembly language for C. Back in the day, C was slow and bloated as compared to hand-crafted assembly. Then people noticed that they wrote more and with fewer bugs with C. Then the compilers got better. Then assembly didn't make much sense except in small niches. Imagine! Writing your UI in a simple text file and handling UI events in a simple scripting language. Don't like the UI colors? Just edit CSS files instead of editing.c files and waiting for the recompile. Your program UI can be as simple as editing a web page!
In C programs, after compilation and linking, the program is ultimately written in machine-language. It's a native program. Similarly, in AbiWord, the cross-platform bit is taken care of at compile-time, leaving you with native widgets at native speed when you run. Mozilla is more like Java. You run the widgets in emulation; the compilation doesn't happen at run-time.
There's a place for emulated languages. Java applets are nice on webpages where speed is less important than portability, and Perl or Python are good for their flexibility. But for a project like Mozilla, I'd rather see it follow the C paradigm, and optimize at compile-time.
With Visual Studio, I can write a web browser with about 30 seconds of coding. One of the included wizards sets me up with an empty window, I tell that window to fill itself with an HTML object, and it does.
I was under the impression the Moz team would be offering something similar, say, a library or DLL (or both) for Gecko. So that to write a web browser, all you'd have to do is link to libgecko, call GeckoView() or something similar, and with minimal lines of code have an HTML object.
Maybe there's a technical reason why that would be hard or impossible; if so, would you mind explaining what it is? If not, though, then I'd very much like to see them do that.
Nope. However popular KDE is on Linux desktops, the fact remains that GTK, which isn't just Gnome, is used almost everywhere. Someone once did a poll; they found that about 7% of respondents used KDE exclusively, 35% used KDE with Gnome apps, 30% used Gnome exclusively, 5% used Gnome with KDE/Qt apps, and the rest used something else. That's not the exact numbers, but the point is, almost every single person using X-windows has GTK, while only KDE users have Qt. Think of GTK as the lowest common denominator (but it's better anyway:D)
Besides, no one's stopping the Moz guys from making both a GTK and a Qt port. The thing is, not only would the GTK port reach a wider audience, most of the people who would have used the Qt port will just use Konqy anyway.
Re:Users designing software: AGHHH!
on
GUIs for Everyone
·
· Score: 1, Flamebait
You know, you inadvertatly gave me a good example of why programmers should not listen to users... or however that programmers should take users wishes with a (big) grain of salt.
Okay, Mr. Elitist Programmer. If you had any good ideas, you didn't let us know; you clearly felt it was adequate to dismiss my ideas out of hand, because I'm a "user". How much "programming", then, will qualify you as a "programmer"? I've done a bit of work in Python; nowhere near as much as most "programmers", but more than 99% of people living in countries rich enough to have computers. Of course, you'll probably just dismiss Python too, saying "Python people are not real developers", or something like that.
Well, seeing as your "programmer" status makes you a demigod, what do *you* think is a good interface? WIMP? You think we should all go around with desktops and windows full of icons, menus three times nested, ten windows on the screen? Or are you a CLI guy: do you think that if people can't figure out that 'lynx' or 'links' is the web browser, then they shouldn't be using computers? Or do you have some new idea for an interface that's hard for most people to use, but you say "Well, I like it"?
Reading on paper is natural. That's a fact. I can't think of anybody who would choose to stare at a monitor if they could be reading on paper instead. Why are e-books so unpopular? People had to stare at ugly screens, with bad resolution and glare. The most popular e-books were the ones that didn't have restrictions on access; so users could just print and go.
Speaking is natural, as is handwriting. And for people, especially those who can't handwrite well, typing has also become natural. But not all people. Any more than good typists should be required to handwrite, why should people who would prefer to handwrite documents be forced to type them?
The reason WIMP sucks so much is because it's so arbitrary. Windows, supposedly trying to parallel the layout of documents on a desk, don't; desks are huge, and screens aren't, meaning that putting multiple windows on a screen requires making both even smaller than they already were.
Icons, I don't know what they were trying to accomplish, but when someone wants to work on a paper document, they remember where it is (ooh! didn't think they could do that?), and start working. Icons suggest that people would rather see a bunch of tiny pictures, with oft-cryptic text underneath, then have to remember that they want to write a document (which is why they turned on their computer in the first place).
Menus were made under the assumption that applications could and should be inifitely bloated, as long as everything that application could do was sorted into categories. Users theoretically would be able to figure out that find was in the edit menu, but preferences were in the edit menu (now the tools menu); you inserted a picture from the insert menu, but you inserted a table from the table menu. In the end, menus required a large amount of recall themselves, so app designers created toolbars and context menus; two improvements that together should have fully replaced the menubar by now, but the same users who learned to remember C-x, C-c, and C-v for cut, copy and paste were apparently too stupid to remember to right-click for more options.
And finally, pointers were created to navigate the whole thing. Again, quite a bad idea; menu items, toolbars, and other control functions would be much better suited with arrow keys, while the documents themselves would be much better suited with absolute positioning, perhaps on a touchscreen.
So, Mr. Elitist Programmer, can you spare the time to explain to a lowly Python programmer like myself *why* it is that my interface idea is so bad (aside from the fact that it creates more work for yourself), and tell me then how an interface *should* be designed? The other three respondents to my comment were nice enough to do just that; I guess I'll have to assume they weren't programmers.
The 'page flipping' navigation requires more manual work and offers no intuitive advantages, it is not intuitive to flip a page twice and see different content... Cool for a demo, but bad for usage, that would suck horribly...
Then make it so that you speak "Next". Or press a button on the end of the page. Or tap your fingers together. Or stare at the last word on the page.
The print thing, that would be hard too.... Basically, you call the document into a view mode completely devoid of visual cues in order to get an acceptable print. Worse yet, printing a book would take a long time if you could only print the current display contents. Removing the visual cues is critically bad for a general purpose interface.
*You*, the user, wouldn't do anything. When you print, you're not printing the current display view contents, you're printing the entire document loaded on the display. If you're reading a book, and you're on page 50, and you press "print", it will print the entire book. You could separately instruct it to only print certain pages, but the default would be the whole book.
Also, setting a different print interface from view interface is trivially easy. You can do it now. You can set Slashdot so that if you want to print an article, it skips the sidebars, and everything but the article itself. No additional work from the user; the computer just recognizes it's printing, loads the print style, and prints.
The general description of your interface seems to be centralized around typing/writing words to navigate. That is recall memory, not very good to ask users to recall from scratch whenever they want to do anything. The advantage of graphical is it exploits much more accessible recognition memory. The visual cues serve to help along the user if unfamiliar. The power of command line interfaces is undeniable, but to insist that a common user should be made to rely upon it again is a step back. GUI wise, I found efm and rox to have the nice compromise, a single keystroke brings access to the command line for powerful stuff and fast access to stuff available to recall memory, but offering the visual cues when things are not etched in stone in my memory...
The common user can't remember they want to check their email? The common user can't remember they want to write a paper? The common user can't remember that they want to surf the web? Why'd they turn their computer on in the first place?! The reason CLIs didn't work is because they expected users to type in "wp" or "ws" to write a document, "ccmail" to email, "terminal", then dial up, and then "lynx" to browse the web. Of course people aren't going to remember that. And there should be a list of applications for when a user needs to do something less common. But all my interface requires people to do is know what task they want to accomplish, and articulate it in a form that a human could understand; if people can't remember that they want to go online or word process, then they probably wouldn't have turned the computer on in the first place.
Do I have to use current tech?
Yay, someone else who thinks like I do!:D More seriously though, good ideas; recognizes that not everyone would want to use the exact same interface, and for the most part it should be computers adapting to people, not the other way around. This doesn't mean people should be complete idiots, just that if people know what they want to do with computers, they shouldn't have to jump through hoops, like turning on a computer, waiting a couple minutes, then finding a n item nested in the Start menu and clicking it.
Just one problem though; part of what makes a keyboard work is the tactile feeling. If the keys didn't go down, it would feel very strange typing; you could do it, but not for very long. Therefore, you'd have to get a device that made your fingers feel like they were pressing down on keys. That's a bit too cyborg-ish for me.
I'm not saying the the WIMP model is the best out there, but we need a lot of thought and research to determine what's going to replace it. So far though, I see few contenders.
As far as I'm concerned, it's about the worst; it's no accident that most users have windows always maximized, that toolbars have become so common, and that keyboards with app-preset buttons have become so popular. The only thing worse than WIMP is a new arbitrary paradigm, like a Doom-esque interface for example. Interface designers need to realize how arbitrary all current interfaces are, and how future ones need to be more natural. Some people don't.
When AbiSource built their word processor, they did most of it cross-platform. You can look, and see that the majority of the source is in the 'xp' directores. But there's a lot of platform-specific code, too. Even though AbiWord is written with a cross-platform GUI layer, when you actually compile AbiWord, it converts the cross-platform widgets into native widgets. Therefore, you can run AbiWord on Windows, GTK, even BeOS, and it will use *native* widgets. Not emulated widgets, native ones. It looks like the platform you're using, because it is.
I understand that the Moz guys want cross-platformability. But XUL is bloated and slow. The Moz team should know full well that the only reason anyone uses Galeon, or KMeleon, is because Moz is too slow! So why can't they follow the Abi example, and have XUL widgets convert to native at compile-time? They can still use XUL for unsupported platforms, but have native GTK or Win32 widgets for the two most common.
The Mozilla team made a great browser, really. But I think it's fair to say, probably a good half of their prospective users, if not more, would use it except for XUL. They should do something about it.
I've got an interface for you
on
GUIs for Everyone
·
· Score: 5, Interesting
It involves a keyboard and a piece of paper.
I'm being serious.
Want to write something? Pull out a Bluetooth keyboard, and an 8.5 x 11 touch-screen OLED, what I like to call "Bluetooth paper". Start typing on the Bluetooth keyboard, and watch your text appear right on the paper, with quality as good as a laser printer. Or you can dictate it. Or you can handwrite it. It's completely up to you.
Want to check your email? Press a key sequence, or say "email", or write "email", and your email is shown right on the paper. Flip the paper over to see the second page, flip it over again in the same direction to see the next page, flip it in the other direction to go back.
Want to print something? Put the paper near a printer, press a button on the printer, and whatever's on the Bluetooth paper will be printed out on the real paper; a permanent copy.
Want to surf the web? Type in, or handwrite, the URL; the page will load up, viewable on the paper. If you've got another sheet, it can split itself, showing content on one page, and navigation on the other. Touch a link, and it opens up.
Now, tell me you wouldn't want to use an interface like that. The OLEDs and keyboards (of course) are in production today, even if the paper's a bit expensive. All you'd need is a device that would intermediate, that would accept input from whatever source and broadcast the raw pixel data back to the paper. It could be in a hub-like box, in a cellphone, even in a wristband. Anything.
To make it work optimally, you'd need the Bluetooth paper to be a touchscreen. That's not possible yet, but it will be soon; until then, you could use a wireless Bluetooth "remote control", or trackball. Also, you'd need to embed a Bluetooth chip in the OLED; again, if it's not possible today, it will be by this time in 2003.
Revolutionary? Not quite. It's simply making computers more natural. And until what I describe is widely available, we need to make existing computers work more like that. One wonders, why aren't all current desktops running WinCE or Symbian? Both of those OSes are powerful enough to run productivity and email apps, and WinCE is powerful enough to run games, too (if the Dreamcast could use it, so can desktops). Imagine if someone could press the power button on their PC, and have a list of applications come up *instantly*, because the OS is installed in ROM! It might mean multitasking isn't as powerful as it is now, but no users use multitasking anyway; just us geeks, and our boxen are not desktops, but workstations.
So, in the short term, what should we do? Extend the LinuxBIOS project to be a full-featured OS with a Palm-style interface, that can load applications off a hard drive, but caches the most frequently used apps (browser, email, word processor) on flash for fast access. Obviously, X is completely out of the picture; really, gtkfb should be appropriate. Start shipping 64MB flash cards, in USB2, FireWire, and IDE versions, with LinuxBIOS, some GTK launcher applet, Galeon, Balsa, and AbiWord preinstalled; you could charge, say, $150 for the initial device, $20 for future upgrades on CD-ROM (or free download). And make very liberal use of AutoPlay for the CD-ROMs; for example, if someone wanted to play Alpha Centauri, all they need to do is pop in the game, click Install, and *everything* happens for them; in the future, all they need to do is pop in the CD-ROM and it loads. For system upgrades, you pop in the CD, wait for a dialog that says "OK" and ejects the CD, take the disc out, and watch it restart itself.
And better still, we could ship a computer, with a custom mobo (or at least, a mobo with a custom BIOS), that has the whole thing built-in to the computer; so it's even faster than IDE, in fact instantaneous. And that computer could be quite small and cheap. Why? Base it on VIA's VPSD Mini-ITX mobo. Smaller than FlexATX, it clocks in at 17 square centimeters - quite possibly, the world's smallest x86 mobo. It has an embedded processor, and sells for $125 from PriceWatch (including shipping). About the only thing it doesn't have onboard is RAM. You could sell one of these things for cheaper than a Dell, and that's including a 15" flat-panel monitor! As long as it had game support, I imagine lots of people would buy it.
The problem with all the other devices that were like this was that they didn't run standard apps. This box, being a real PC, would run standard apps; it could run most any console or GTK program, even if it required a recompile. The killer app, though, would be games. Sell the box in two editions; regular, and gamer's edition. The game one comes with a GeForce 4 Ti (or the latest card at the time), VGA-to-RCA converter cable, and no monitor.
Sounds like a console? So it is; essentially the Linux version of Xbox. But it can also be used as a regular computer; considering that, it wouldn't cost very much at all, and importantly, neither would the games. No subsidised loss-leaders here.
So, enough of my rambling. Between all these ideas, we should be able to do *something*. So why aren't we?
If you want a clean design, look at Alpha or MIPS.
As it happens, the vast majority of former Alpha engineers, including the full EV8 team, are now employed at Intel. That means that a good number of the people working on Itanium and its successors were very closely involved in making the cleanest architecture of all.
AMD, on the other hand, is made up 100% of CISC people. You can say "CISC is almost as good as RISC" as much as you want, but the fact remains that RISC is better than CISC. It's like parallel versus serial. Parallel's supposed to be faster, so how come USB replaced parallel ports and Serial ATA replaced ATA/100? Because at superfast speeds, the complexity of parallel didn't work.
Intel and AMD, together holding a huge majority of all microprocessors on the planet, have spent years doing tons and tons of CISC R&D. By contrast, the work Sun, IBM, Motorola, and Digital/Compaq have done on their respective architectures is miniscule. Don't you remember back in 1995, when the Pentium II 3000 was brand-new, and Digital ran ads everywhere for the Alpha 500MHz? The Alpha never got much faster than that, because Digital didn't have the marketshare to warrant it or the money to do it.
Of course, this just returns to an earlier point I made. If the future of the PC is more of the same shit it's had since 1980, with IRQs, convoluted chip architectures, megahertz over actual performance, and now Palladium, why bother? The iBook is one of the cheapest laptops on the market, the TiBook is one of the (arguably the) best, and the G4 tower, while not a speed demon, offers the best multiprocessor support in a mainstream desktop. Buy one of them, buy a copy of LinuxPPC, and support the only computer company that still cares about innovation.
.net is not evil
on
.NET for Apache
·
· Score: 5, Interesting
Call me a heretic, but I think.net is a good thing. Not.net as made by Microsoft, but.net as an open standard - for example Mono. The concept of making Web services as easy to run and use as regular applications.
I don't want to have everything run on a server and use a dumb terminal. No sense making it even easier for Ashcroft to read my stuff than it already is. But Web services, by nature, are things that already use the Internet - things that might as well be hanging on a building in Times Square, for all Ashcroft cares.
To check stocks, I have to go to cnbc.com. It's an ugly interface. Why can't I double-click on a program that uses native widgets and displays that same information? To read and reply to Slashdot, I have to slashdot.org. It's uglier than a female dwarf (or KDE). Why can't I have Slashdot in a Win32-native interface? Think NNTP, but better-looking and more powerful.
To write a document, I open up AbiWord. If I'm writing a story about the stock market, why can't I just open up my stock market program, drag a box into my document, and have live numbers for the Dow? If I'm writing a story about AMD, why can't I just open up my Slashdot program, drag a box into my document, and have a link to the story inserted into my document; and why can't the person on the other end open the document, double-click my link, and have the Slashdot story opened in place - without needing a web browser?.net is simply recognizing the reality that the Internet is a dynamic medium, and it requires a new way of designing programs; a way that makes using the Web identical to using your computer locally. All of the examples I just gave can be done now with existing programming tools on any platform, but.net makes it much easier and more straightforward. It's nothing particularly difficult, and open source will be quick to replicate it.
As Miguel de Icaza said, you shouldn't just not use Mono because it's a copy of a MS product - after all, Linux itself is a copy of non-free UNIX from AT&T. If/when the time comes that Microsoft decides to cut off.net for Apache support, Mono will be ready to take its place.
The Opteron is compatible with all software made since the 8086. Therefore, the Opteron cannot truly be called new technology. It may have evolved in certain ways, but at its core it is no more advanced than the 8086. You can read AMD's whitepaper, and it will confirm: AMD knows that RISC, or specifically VLIW, is faster than CISC, but doesn't want to switch because of the installed base.
Intel, with the Itanium, takes the opposite stance. They know that CISC sucks, and that x86 was doomed from the start. It's not that "new things are better"; VLIW processors could have been developed in 1980, and if they were there would be no need for Itanium. But they didn't. So Intel wants to use 64-bit as an excuse to throw out x86, and start over the way they should have from the beginning.
Let's hope that Intel uses it's 75% marketshare power to win. It'll be unfortunate if AMD does.
Hmm... I'm guessing the framebuffer device,/dev/fb/0 or/dev/fb0, is set to root-only. Try changing that to have user-accessible permissions; the former if you have devfs, the latter if you don't.
Ever used links? No, really? For a while now, it's had this really nice option, -g. Load it up, and it'll load links in the framebuffer. Full graphics, no X. It's fine, because the average user can't multitask in real life, let alone on a computer.
If Uncle Joe multitasks, it just means that he has Outlook Express open in the background checking his email while he writes a letter. He'll never have two tasks open in the foreground. Never! Find me a single Windows user who routinely doesn't have all their windows maximised. Sure, every so often they might use 'tile', but that's about it.
The thing is, most people want pretty pictures. So what do you do? Simple. First, make the kernel compilable in single-user-only mode; there can still be Win98-style 'user profiles', but no real system-level multiuser support - that will just confuse users and bloat the system.
Next, load the framebuffer on startup. Hide all boot messages, and insteaad just display a stylized, *huge* penguin (not the one they do now, bigger) in the style of the Windows boot screen.
When it finishes loading, instead of seeing a standard login prompt, the user sees a row of icons on the top of the screen with default apps (mail, browser, word processor), a help button, their chosen background image, and a command prompt. With accelerated framebuffer support, the graphics look as nice as those on Windows. Almost everything a user needs to do, they can do with the default icons, and anything else they can just type in the commands. (The buttons on top are like the ones on the WinXP start panel - after a week or so of use, they become the most common programs the user runs.) If a user needs to multitask, that's what 'screen' is for.
You know, it can't be that hard to do this... now I'm going to try to make a distro with [a] a modified FS, [b] a better package-installing system, and [c] this kind of interface. Except that I can't code.:D But I'll learn. Most of what I'm doing is just removing and rearranging code, anyway.
Slashdot Mirror
Maybe I didn't make it clear enough. Says right in my comment: "Users could put a cap on the maximum amount they could pay/transfer in any one month." Especially if an exemption was made for the cableco's own servers, I think that would take care of your problem. You might accidentally lose connectivity after ten days if you download too much, but you'd be able to check your email no matter what, and next month you'd be a bit more conscientious in your use.
Most people don't want IM. Most people don't want email. Most people don't want websites. Most people don't even want phone; it's better if they're inaccessible, so they can get work done without having to deal with the phone.
Of course people don't use the high bandwidth because they aren't interested. The technology isn't cheap and accessible enough to use it. If videoconferencing really worked as well as face-to-face meetings, do you think anybody would fly out from Boston to go to a meeting in LA?
No one knows how to use this extra bandwidth yet, that's just the point. We need to give room to try out these technologies. It's the chicken and the egg: AT&T won't make bandwidth available because people don't use it, and people aren't developing applications for the high bandwidth because nobody has it. AT&T should realize this and make the first move. Later, they'll realize they made the right choice.
No. A system that works is not a system where companies can exploit users who guess too low or too high about their usage habits; a system that works is one where consumers pay exactly for what they use, and nothing more.
Suppose AT&T started offering lines for $10/mo, with bandwidth running for $5/Gb, incremented in bytes. (As usual, the numbers are bullshit.) A user who transferred 1 gigabyte of content a month would pay $15. A user who transferred 10 megabytes of content a month would pay $10.50. A user who transferred 10 gigabytes of content would pay $60. You wouldn't pay in advance, or buy "blocks of bytes", or anything stupid like that; you'd just pay for what you actually use. Users could put a cap on the maximum amount they could pay/transfer in any one month, but otherwise they could use as little or as much as they want.
Now personally, I don't like the idea of a system like that; like I said before, if bandwidth costs money, then high-bandwidth applications aren't going to take off. The optimal system is ubiquitous wireless. The next-best system is probably what I described above. Another alternative system is daily caps; i.e. instead of being able to download 1.5 mb/s, you can transfer 16 gigabytes a day, but you can do it as fast as your cable modem will technically allow; if it formerly took an hour to download an ISO, maybe now you can do it in twenty minutes; but download too many and that's your internet use for the day.
The current system of speed caps is pretty bad, but the only thing worse is tiered speed caps.
As I said we should do in my other post to this article.
Until that happens; bandwidth may not grow on trees, but there's way more of it out there than we know what to do with. Backbone providers don't charge for speed, they charge for data; AT&T pays not according to how fast, but to how much. Therefore, it only makes sense that users should be able to do the same.
I did the calculation in another post; I don't have the number with me now, but this point is, I have an effective usage cap consisting of some huge amount of data per month, assuming I'm on 24/7 using full speed connections; so why can't I use that as quickly as I want? If I want to download an ISO image in a minute, and then that's my only network usage for the day, why not?
It seems strange to me how many slashdotter seems to deeply distrust the free market (it must be Microsoft that did it...).
And it seems strange to me how many Slashdotters seem to deeply mistrust anything but the free market; there are many more anarcho-capitalists than anarcho-communists on this site, it seems, despite Microsoft.
Sure, people who know they need the bandwidth and can afford it will pay extra. The thing is, if it doesn't cost AT&T anything at all to provide the extra speed, and it doesn't, then charging different prices for different speeds is nothing less than exploitation. To be honest, bandwidth caps make much more sense than speed caps. 3942000 megabits per month is the most I can get from my cable modem... why can't I get it as fast as I wantT?
This just proves why we need ubiquitous wireless internet.
To all you who would say that there are health problems: Bah. There's already tons of wireless signals going through the air with radio and TV, and you don't see everyone getting cancer, do you?
TV, especially now that it's becoming digital, can easily be transferred over the Internet. Radio can easily be transferred over the Internet (look at Shoutcast). IPv6 insures that there are enough IP addresses that every person on the planet can have a subnet and we're nowhere near running out. So why not just make everything go over the Internet?
Take away all public TV wireless broadcasts, and all radio broadcasts. Then, in their place, start broadcasting wireless networks, everywhere. Completely for free. Radios are reworked to use IPv6 and pick up Internet signals; TVs the same. Support for 802.11g, or a newer protocol, is built into every single computer, TV, car; the list goes on.
There's another important impact if this happens: you're no longer paying for connectivity, so that money is freed up for other uses. People who are now paying $10/mo for NetZero, $23/mo for AOL, or $50/mo for AT&T Broadband now can use that money to pay for premium content. Micropayments can be instituted on a mass scale; most people would only end up spending about $10/mo anyway on micropayments, and power users who spend huge amounts of time on the Internet just pay more. People get the same speed no matter what.
Why not?
I watch in vain as yet more people fail to understand the evils of tiered pricing.
Recently, Case Western University decided to equip thousands of computers with a 1gb/s fiber network. They didn't quite know what people would use the bandwidth for, but they wanted to find out.
Why am I bringing this up? Ordinary users will only pay AT&T the cheapest price possible for a broadband connection. Now, that's $45; soon, AT&T may introduce a $20-$25 package, and theoretically some people now paying the higher price would downgrade to that package.
But there's tons of high-bandwidth applications available that most people don't use yet. Imagine real-time videoconferencing with resolutions as good as a printer. Imagine downloading OS or application upgrades from the Net in seconds. Hell, who would need hard drives anymore; bandwidth would be faster! There's all sorts of things we haven't thought of yet. But as long as AT&T imposes artificial bandwidth caps, that won't happen.
As bad as tiered pricing are upstream caps. That means that two cable modem users can only communicate with each other at ISDN speeds. There goes any useful peer-to-peer connectivity applications. Don't you all remember back when you used Napster, you'd always sort downloads by modem type, and skip anything lower than a T1? Downloading from one of your fellow cable modem users would have taken 8 times as long as downloading from someone with a leased line - but we can't all have leased lines, can we?
Tiered pricing is fine if it's due to technical constraints. If cable lines in San Francisco and Boston, for example, are higher-quality than lines elsewhere, there would be nothing wrong with offering faster service. But AT&T cannot justify offering service slower than what the cable lines allow; doing that will do much to halt the pace of network innovation. Shame on all providers who offer anything less than network capacity, in both directions.
First off, let me say that I just tried downloading Mozilla 1.1 beta for Win32 on a 750 MHz Duron, and was surprised to find that everything worked in real-time. Then again, maybe I shouldn't be, given that my last experience was on BeOS on a 466 MHz Celeron. :D
Then again, Mozilla could be released as native widget versions. But then why would anyone use Galeon, K-Meleon, or Chimera. Aren't those native widget ports of Mozilla? Isn't that what you asked for: a default build of XUL with popular platforms having a native widget option? Where's the problem?
Chimera - good example. Chimera browser is part of Mozilla; it's website is chimera.mozdev.org . Chimera uses Aqua, for everything - scrollbars, checkboxes, etc. Therefore, there's no Galeon-like independent port for OS X, because who needs it? In other words, Moz team should do Chimera for Win32 and GTK, too. That's all I want.
So all UI code should be compiled eh? What if XUL were compiled? Would you still have objection to it? I ask because recent Mozilla builds (including 1.0) have a file called XUL.mfasl. To quote the release notes
I think that, on major platforms, Mozilla should render XUL code using native widget libraries instead of its custom libraries, like it does with Chimera on OS X. They should still use XUL, just abandon "Modern" and instead use Win32 or GTK. Not for speed, but for consistency. That's all.
try and confuse me with numbers all you want, all I know is that my KDE with Mosfet's Liquid engine looks far prettier than and Gnome app I've seen :)
:D
:D But that'll never happen.
It's nice... though I expect, during practical use, ThinIce is better. Ever used ThinIce, or its superior variant MoonIce? Best engine I've ever seen, mainly for it's speed and clean-ness. It's not the best looking, but I don't pick my widgets for art; I've got my desktop background, and transparent windows, for that.
seriously though, I think they do have both a GTK and a Qt port, I've just never bothered to get it to work. btw, from your numbers 42% use KDE and 35% use Gnome (with or without the other toolkit's apps), wouldn't it stand to reason that more people would want the Qt port, for their "native" as it were environment?
No. First, that leaves off the huge numbers of people who use a different environment; wmaker, enlightenment, blackbox, even fvwm. Second, building on that, gtk is the lowest common denominator. Let's say 50% of people have qt installed. Hell, let's say 80% of people have qt installed. Well, 100% of people have GTK installed. There should be a port for both, but the GTK one first.
It's a non-issue anyway; both the GTK and Qt teams should abandon work now and switch over to Fresco.
I personally use both Mozilla and Konqy. while Konq is prettier (better looking/better anti-aliased fonts is the biggest thing here) and plays better with the rest of the environment, Mozilla is just an all around better browser. why so many people seem to think that you have to use only one browser, anyway?
One browser should be flexible enough to handle all situations. Maybe you have two different shortcuts, one to open it in minimal-mode and one to open it in full-featured mode, but it should be able to handle all situations.
Now, what I'd love to see is a port of Konqy to Gnome2.
Good news... sawfish, available today, supports one-dimensional virtual desktops (i.e. you can have five in a line, but not four in a square), and is Gnome2 native. Maybe you've been using metacity?
Yes, KHTML is a great browser. And this just goes to show the stupidity of both the KDE and Gnome teams.
I think it's fair to say that over half of the code that goes into KDE and Gnome has absolutely nothing to do with GUIs. Sure, it'll be used in a GUI context, but the code itself is completely GUI independent. Like drag-and-drop, for example.
So, how come the KDE and Gnome teams don't just unite under a common desktop framework, and have the only separate thing be the Qt- or GTK-specific parts? It would improve development so much, make it easier for other desktops to be compatible with both, make it easier for application developers to write programs for both (they only need to use two widgets, not two desktops), and make Linux more consistent.
Ah, I hope that someday, freedesktop.org is complete...
Until then... I could just compile konqy as a standalone app with staticly-linked Qt and kde-libs, right?
Okay, I've been trolled. C'mon now. "A couple of seconds"? I'm writing this on a P2-300 Vaio laptop. If a menu took a single second to load, Mozilla would be usuable for me. I seriously doubt that you have used Mozilla in the last year. If you have, then you are just lying or trying to run it on a 486 with 16MB of RAM.
Last time I used Mozilla, it was last week; the 19-July build for BeOS. Compared to everything else in BeOS, it was damn slow; so slow that I routinely used NetPositive, with its horrible rendering engine, just to avoid loading Moz.
Optimize the preferences dialog algorithms, and XUL will seem faster.
Fair enough, except that my only complaint with the prefs, at least as compared to the rest of XUL, is that they routinely won't save. They're no slower than anything else, for me at least.
AbiWord supports Windows, Linux, FreeBSD, Mac OS X, and QNX. That's it.
So I guess my copy of AbiWord on BeOS was just a dream then? No, probably not, seeing that it's right here. It doesn't support Mac OS 9 because that's a dead OS.
Also, if you'll read my original post, I don't think XUL should be completely scrapped. I simply think that, on the more popular platforms, XUL should be eschewed in favor of native widgets. Use XUL for AmigaOS, Mac OS 9, and other dead OSes; use native widgets for Windows and GTK.
My point was that Galeon does less than Mozilla. In addition, I believe that a new XUL "theme" (for lack of a better word) could make Mozilla look exactly like Galeon with comparable speed.
I've used themes that have not a single button (simply a URL bar), yet they're slower than Galeon. When I dual-boot into Windows, to run IE, a web browser that does as much as Mozilla, IE runs circles around Moz. So, why?
Sounds very similar to the arguments you are making now.
I have a new slogan for XUL. It's "write once, run anywhere." Oh wait, that's someone else's slogan - Java! Do you think that we should all start programming in Java instead? I think that C is good, Objective C is better, and eventually even higher-level languages should be used. But I think, for the most part, they should always be compiled, not emulated. Clearly most other people agree with me; if write-once run-anywhere was so good, Windows would be written in Java right now.
How about twenty years ago when the X Windows System was first being proposed. Why on earth would anyone want a universal windowing system? It will be the death of innovation and speed.
Funny you should bring that up - I've been advocating the mass deployment of Berlin, now Fresco, for a while now. Because Fresco's much higher-level than X, and will therefore make xplatformability easier. But Fresco is written in C++, and when you run Fresco on your computer, you're running a machine language app. It would be absurd to write Fresco, or X, in Java; it would be insanely slow. Instead, they're written in C/C++; portable to multiple platforms, but fast.
research project after research project has demonstrated that productivity skyrockets after using a scripting language in place of a compiled language like C. These same real-world study documents also demonstrate no great speed increase in most (>90%) applications when C is used.
Productivity for what? I agree that most small apps should be written in some form of a scripting language, as Perl/Python (Parrot!) has become fast enough for most use. Especially for console apps; how great it is to have one console Jabber client that I can run on every platform (yes, it exists). But something like Mozilla is so huge that writing it in an emulated language won't work.
Remember Knuth's 80-20 rule? You did read Knuth's work right? 80% of running time is in 20% of the code. How much time do you think the UI is taking in processing time? Let's suppose for the moment that you're right, I'm wrong, and XUL is the source of all of the problems with speed in Mozilla. In most browsing sessions, I barely touch the menubar; most of my time is spent in the main browser area. If I'm not interacting with XUL most of the time, how can it be such a horrible timesink in real-world use.
I don't know about you, but it's rare that I can get Moz to accept keyboard shortcuts. For whatever reason, it fails to do so. Therefore, I often have to resort to the back and forward buttons. It shouldn't take upwards of 5 seconds to even select "back", as it did on Be. Maybe it's better on other platforms, but not on Be.
That said, I assert that you have not put a profiler on Mozilla and are talking out of your ass with regard to the XUL engine. You might say that the UI design is bad. You might say that some of the backend component calls could use some optimization, but when you say that XUL is too slow to comfortably use, you sound like a fool.
Whereas your insults make you sound more intelligent. I might say that XUL is bad from a philosophical standpoint. I think that all widgets should be consistent. That's why I like Fresco; finally, no more toolkits, everything is consistent, and themes are universal. That's why I hate skins, and why I generally resort to using mpg321 (GPLed clone of mpg123) to play audio, because I can't find a skin-free GTK player. In the case of xmms, I'll freely admit that skins don't make it any slower, and that most of the player is in GTK anyhow. But, in my opinion, the whole concept of a desktop that has ten different programs with ten completely different looks is beyond me. On win32 and GTK, Moz should use native widgets, not for the speed but for consistency.
If you want consistency of browser UI when using multiple operating systems (as I do), then use Modern. If you want something more akin to a native feel, use classic. If you absolutely want native widgets, use Galeon, K-Meleon, or Chimera. That's what these projects are there for!
.c files and waiting for the recompile. Your program UI can be as simple as editing a web page!
That's the thing. Why do you want consistency of browser UI between multiple operating systems over consistency within an OS? It's the rare OS that isn't themable; why don't you just pick a look that you like, say Modern, set the entire OS to look like that, and have Moz use native widgets?
As a side note, XUL is rendered by Gecko. You can't say that one is slow while the other is fast. They are different limbs of the same beast.
For text, it's fine. For everything else, Gecko is slow. As pages are mostly text, the slowness of Gecko doesn't matter much; for XUL, you really notice it, especially because normally, widgets are faster than any other part of the UI (even when Gecko isn't a factor).
The reason that Mozilla developers can handle the large number of platforms that Mozilla runs on is because of XUL. The code is amazing in its cross-platform purity. Fix a mail client bug here and it's fixed everywhere. Fix a UI bug there and its fixed everywhere. Contrast this with fixing a UI bug in the Windows code and it must be fixed in Mac (OS 9- and OS 10+), X (Xlib, GTK+ and Qt ports), BeOS, OS/2, OpenVMS(!), Amiga, etc.
AbiWord is the same way, but it uses native widgets, and clicking an AbiWord menu works instantaneously, whereas clicking a Moz menu takes multiple seconds to load - it just doesn't feel clean.
I'm not saying that XUL didn't take a long time. I'm not saying that it saved a whole lot of development time until recently. What I am asserting is that all new bugfixes and enhancements can now happen much faster (and have been for the last year or so) than would be possible with native libraries and widgets. And it's not like Mozilla isn't modular and reusable; how do you think Galeon and K-Meleon were able to be released so quickly? They whipped up a barebones UI up on the infrastructure written by Mozilla developers. If you like Galeon, K-Meleon, and Chimera, it probably has more to do with liking barebones UIs than an inherent deficiency in Mozilla's UI. That said, if that's your preference, more power to you. Just don't shit on someone else's meal when your food comes from the same kitchen.
I suppose you like Word's UI then? Or would you rather use a less bloated word processor?
Honestly, I don't know a single person who truly prefers complex interfaces to simple ones.
What the Mozilla developers have done is akin to shunning assembly language for C. Back in the day, C was slow and bloated as compared to hand-crafted assembly. Then people noticed that they wrote more and with fewer bugs with C. Then the compilers got better. Then assembly didn't make much sense except in small niches. Imagine! Writing your UI in a simple text file and handling UI events in a simple scripting language. Don't like the UI colors? Just edit CSS files instead of editing
In C programs, after compilation and linking, the program is ultimately written in machine-language. It's a native program. Similarly, in AbiWord, the cross-platform bit is taken care of at compile-time, leaving you with native widgets at native speed when you run. Mozilla is more like Java. You run the widgets in emulation; the compilation doesn't happen at run-time.
There's a place for emulated languages. Java applets are nice on webpages where speed is less important than portability, and Perl or Python are good for their flexibility. But for a project like Mozilla, I'd rather see it follow the C paradigm, and optimize at compile-time.
Speaking of modular...
With Visual Studio, I can write a web browser with about 30 seconds of coding. One of the included wizards sets me up with an empty window, I tell that window to fill itself with an HTML object, and it does.
I was under the impression the Moz team would be offering something similar, say, a library or DLL (or both) for Gecko. So that to write a web browser, all you'd have to do is link to libgecko, call GeckoView() or something similar, and with minimal lines of code have an HTML object.
Maybe there's a technical reason why that would be hard or impossible; if so, would you mind explaining what it is? If not, though, then I'd very much like to see them do that.
Nope. However popular KDE is on Linux desktops, the fact remains that GTK, which isn't just Gnome, is used almost everywhere. Someone once did a poll; they found that about 7% of respondents used KDE exclusively, 35% used KDE with Gnome apps, 30% used Gnome exclusively, 5% used Gnome with KDE/Qt apps, and the rest used something else. That's not the exact numbers, but the point is, almost every single person using X-windows has GTK, while only KDE users have Qt. Think of GTK as the lowest common denominator (but it's better anyway :D)
Besides, no one's stopping the Moz guys from making both a GTK and a Qt port. The thing is, not only would the GTK port reach a wider audience, most of the people who would have used the Qt port will just use Konqy anyway.
You know, you inadvertatly gave me a good example of why programmers should not listen to users... or however that programmers should take users wishes with a (big) grain of salt.
Okay, Mr. Elitist Programmer. If you had any good ideas, you didn't let us know; you clearly felt it was adequate to dismiss my ideas out of hand, because I'm a "user". How much "programming", then, will qualify you as a "programmer"? I've done a bit of work in Python; nowhere near as much as most "programmers", but more than 99% of people living in countries rich enough to have computers. Of course, you'll probably just dismiss Python too, saying "Python people are not real developers", or something like that.
Well, seeing as your "programmer" status makes you a demigod, what do *you* think is a good interface? WIMP? You think we should all go around with desktops and windows full of icons, menus three times nested, ten windows on the screen? Or are you a CLI guy: do you think that if people can't figure out that 'lynx' or 'links' is the web browser, then they shouldn't be using computers? Or do you have some new idea for an interface that's hard for most people to use, but you say "Well, I like it"?
Reading on paper is natural. That's a fact. I can't think of anybody who would choose to stare at a monitor if they could be reading on paper instead. Why are e-books so unpopular? People had to stare at ugly screens, with bad resolution and glare. The most popular e-books were the ones that didn't have restrictions on access; so users could just print and go.
Speaking is natural, as is handwriting. And for people, especially those who can't handwrite well, typing has also become natural. But not all people. Any more than good typists should be required to handwrite, why should people who would prefer to handwrite documents be forced to type them?
The reason WIMP sucks so much is because it's so arbitrary. Windows, supposedly trying to parallel the layout of documents on a desk, don't; desks are huge, and screens aren't, meaning that putting multiple windows on a screen requires making both even smaller than they already were.
Icons, I don't know what they were trying to accomplish, but when someone wants to work on a paper document, they remember where it is (ooh! didn't think they could do that?), and start working. Icons suggest that people would rather see a bunch of tiny pictures, with oft-cryptic text underneath, then have to remember that they want to write a document (which is why they turned on their computer in the first place).
Menus were made under the assumption that applications could and should be inifitely bloated, as long as everything that application could do was sorted into categories. Users theoretically would be able to figure out that find was in the edit menu, but preferences were in the edit menu (now the tools menu); you inserted a picture from the insert menu, but you inserted a table from the table menu. In the end, menus required a large amount of recall themselves, so app designers created toolbars and context menus; two improvements that together should have fully replaced the menubar by now, but the same users who learned to remember C-x, C-c, and C-v for cut, copy and paste were apparently too stupid to remember to right-click for more options.
And finally, pointers were created to navigate the whole thing. Again, quite a bad idea; menu items, toolbars, and other control functions would be much better suited with arrow keys, while the documents themselves would be much better suited with absolute positioning, perhaps on a touchscreen.
So, Mr. Elitist Programmer, can you spare the time to explain to a lowly Python programmer like myself *why* it is that my interface idea is so bad (aside from the fact that it creates more work for yourself), and tell me then how an interface *should* be designed? The other three respondents to my comment were nice enough to do just that; I guess I'll have to assume they weren't programmers.
The 'page flipping' navigation requires more manual work and offers no intuitive advantages, it is not intuitive to flip a page twice and see different content... Cool for a demo, but bad for usage, that would suck horribly...
:D More seriously though, good ideas; recognizes that not everyone would want to use the exact same interface, and for the most part it should be computers adapting to people, not the other way around. This doesn't mean people should be complete idiots, just that if people know what they want to do with computers, they shouldn't have to jump through hoops, like turning on a computer, waiting a couple minutes, then finding a n item nested in the Start menu and clicking it.
Then make it so that you speak "Next". Or press a button on the end of the page. Or tap your fingers together. Or stare at the last word on the page.
The print thing, that would be hard too.... Basically, you call the document into a view mode completely devoid of visual cues in order to get an acceptable print. Worse yet, printing a book would take a long time if you could only print the current display contents. Removing the visual cues is critically bad for a general purpose interface.
*You*, the user, wouldn't do anything. When you print, you're not printing the current display view contents, you're printing the entire document loaded on the display. If you're reading a book, and you're on page 50, and you press "print", it will print the entire book. You could separately instruct it to only print certain pages, but the default would be the whole book.
Also, setting a different print interface from view interface is trivially easy. You can do it now. You can set Slashdot so that if you want to print an article, it skips the sidebars, and everything but the article itself. No additional work from the user; the computer just recognizes it's printing, loads the print style, and prints.
The general description of your interface seems to be centralized around typing/writing words to navigate. That is recall memory, not very good to ask users to recall from scratch whenever they want to do anything. The advantage of graphical is it exploits much more accessible recognition memory. The visual cues serve to help along the user if unfamiliar. The power of command line interfaces is undeniable, but to insist that a common user should be made to rely upon it again is a step back. GUI wise, I found efm and rox to have the nice compromise, a single keystroke brings access to the command line for powerful stuff and fast access to stuff available to recall memory, but offering the visual cues when things are not etched in stone in my memory...
The common user can't remember they want to check their email? The common user can't remember they want to write a paper? The common user can't remember that they want to surf the web? Why'd they turn their computer on in the first place?! The reason CLIs didn't work is because they expected users to type in "wp" or "ws" to write a document, "ccmail" to email, "terminal", then dial up, and then "lynx" to browse the web. Of course people aren't going to remember that. And there should be a list of applications for when a user needs to do something less common. But all my interface requires people to do is know what task they want to accomplish, and articulate it in a form that a human could understand; if people can't remember that they want to go online or word process, then they probably wouldn't have turned the computer on in the first place.
Do I have to use current tech?
Yay, someone else who thinks like I do!
Just one problem though; part of what makes a keyboard work is the tactile feeling. If the keys didn't go down, it would feel very strange typing; you could do it, but not for very long. Therefore, you'd have to get a device that made your fingers feel like they were pressing down on keys. That's a bit too cyborg-ish for me.
I'm not saying the the WIMP model is the best out there, but we need a lot of thought and research to determine what's going to replace it. So far though, I see few contenders.
As far as I'm concerned, it's about the worst; it's no accident that most users have windows always maximized, that toolbars have become so common, and that keyboards with app-preset buttons have become so popular. The only thing worse than WIMP is a new arbitrary paradigm, like a Doom-esque interface for example. Interface designers need to realize how arbitrary all current interfaces are, and how future ones need to be more natural. Some people don't.
When AbiSource built their word processor, they did most of it cross-platform. You can look, and see that the majority of the source is in the 'xp' directores. But there's a lot of platform-specific code, too. Even though AbiWord is written with a cross-platform GUI layer, when you actually compile AbiWord, it converts the cross-platform widgets into native widgets. Therefore, you can run AbiWord on Windows, GTK, even BeOS, and it will use *native* widgets. Not emulated widgets, native ones. It looks like the platform you're using, because it is.
I understand that the Moz guys want cross-platformability. But XUL is bloated and slow. The Moz team should know full well that the only reason anyone uses Galeon, or KMeleon, is because Moz is too slow! So why can't they follow the Abi example, and have XUL widgets convert to native at compile-time? They can still use XUL for unsupported platforms, but have native GTK or Win32 widgets for the two most common.
The Mozilla team made a great browser, really. But I think it's fair to say, probably a good half of their prospective users, if not more, would use it except for XUL. They should do something about it.
It involves a keyboard and a piece of paper.
I'm being serious.
Want to write something? Pull out a Bluetooth keyboard, and an 8.5 x 11 touch-screen OLED, what I like to call "Bluetooth paper". Start typing on the Bluetooth keyboard, and watch your text appear right on the paper, with quality as good as a laser printer. Or you can dictate it. Or you can handwrite it. It's completely up to you.
Want to check your email? Press a key sequence, or say "email", or write "email", and your email is shown right on the paper. Flip the paper over to see the second page, flip it over again in the same direction to see the next page, flip it in the other direction to go back.
Want to print something? Put the paper near a printer, press a button on the printer, and whatever's on the Bluetooth paper will be printed out on the real paper; a permanent copy.
Want to surf the web? Type in, or handwrite, the URL; the page will load up, viewable on the paper. If you've got another sheet, it can split itself, showing content on one page, and navigation on the other. Touch a link, and it opens up.
Now, tell me you wouldn't want to use an interface like that. The OLEDs and keyboards (of course) are in production today, even if the paper's a bit expensive. All you'd need is a device that would intermediate, that would accept input from whatever source and broadcast the raw pixel data back to the paper. It could be in a hub-like box, in a cellphone, even in a wristband. Anything.
To make it work optimally, you'd need the Bluetooth paper to be a touchscreen. That's not possible yet, but it will be soon; until then, you could use a wireless Bluetooth "remote control", or trackball. Also, you'd need to embed a Bluetooth chip in the OLED; again, if it's not possible today, it will be by this time in 2003.
Revolutionary? Not quite. It's simply making computers more natural. And until what I describe is widely available, we need to make existing computers work more like that. One wonders, why aren't all current desktops running WinCE or Symbian? Both of those OSes are powerful enough to run productivity and email apps, and WinCE is powerful enough to run games, too (if the Dreamcast could use it, so can desktops). Imagine if someone could press the power button on their PC, and have a list of applications come up *instantly*, because the OS is installed in ROM! It might mean multitasking isn't as powerful as it is now, but no users use multitasking anyway; just us geeks, and our boxen are not desktops, but workstations.
So, in the short term, what should we do? Extend the LinuxBIOS project to be a full-featured OS with a Palm-style interface, that can load applications off a hard drive, but caches the most frequently used apps (browser, email, word processor) on flash for fast access. Obviously, X is completely out of the picture; really, gtkfb should be appropriate. Start shipping 64MB flash cards, in USB2, FireWire, and IDE versions, with LinuxBIOS, some GTK launcher applet, Galeon, Balsa, and AbiWord preinstalled; you could charge, say, $150 for the initial device, $20 for future upgrades on CD-ROM (or free download). And make very liberal use of AutoPlay for the CD-ROMs; for example, if someone wanted to play Alpha Centauri, all they need to do is pop in the game, click Install, and *everything* happens for them; in the future, all they need to do is pop in the CD-ROM and it loads. For system upgrades, you pop in the CD, wait for a dialog that says "OK" and ejects the CD, take the disc out, and watch it restart itself.
And better still, we could ship a computer, with a custom mobo (or at least, a mobo with a custom BIOS), that has the whole thing built-in to the computer; so it's even faster than IDE, in fact instantaneous. And that computer could be quite small and cheap. Why? Base it on VIA's VPSD Mini-ITX mobo. Smaller than FlexATX, it clocks in at 17 square centimeters - quite possibly, the world's smallest x86 mobo. It has an embedded processor, and sells for $125 from PriceWatch (including shipping). About the only thing it doesn't have onboard is RAM. You could sell one of these things for cheaper than a Dell, and that's including a 15" flat-panel monitor! As long as it had game support, I imagine lots of people would buy it.
The problem with all the other devices that were like this was that they didn't run standard apps. This box, being a real PC, would run standard apps; it could run most any console or GTK program, even if it required a recompile. The killer app, though, would be games. Sell the box in two editions; regular, and gamer's edition. The game one comes with a GeForce 4 Ti (or the latest card at the time), VGA-to-RCA converter cable, and no monitor.
Sounds like a console? So it is; essentially the Linux version of Xbox. But it can also be used as a regular computer; considering that, it wouldn't cost very much at all, and importantly, neither would the games. No subsidised loss-leaders here.
So, enough of my rambling. Between all these ideas, we should be able to do *something*. So why aren't we?
If you want a clean design, look at Alpha or MIPS.
As it happens, the vast majority of former Alpha engineers, including the full EV8 team, are now employed at Intel. That means that a good number of the people working on Itanium and its successors were very closely involved in making the cleanest architecture of all.
AMD, on the other hand, is made up 100% of CISC people. You can say "CISC is almost as good as RISC" as much as you want, but the fact remains that RISC is better than CISC. It's like parallel versus serial. Parallel's supposed to be faster, so how come USB replaced parallel ports and Serial ATA replaced ATA/100? Because at superfast speeds, the complexity of parallel didn't work.
Intel and AMD, together holding a huge majority of all microprocessors on the planet, have spent years doing tons and tons of CISC R&D. By contrast, the work Sun, IBM, Motorola, and Digital/Compaq have done on their respective architectures is miniscule. Don't you remember back in 1995, when the Pentium II 3000 was brand-new, and Digital ran ads everywhere for the Alpha 500MHz? The Alpha never got much faster than that, because Digital didn't have the marketshare to warrant it or the money to do it.
Of course, this just returns to an earlier point I made. If the future of the PC is more of the same shit it's had since 1980, with IRQs, convoluted chip architectures, megahertz over actual performance, and now Palladium, why bother? The iBook is one of the cheapest laptops on the market, the TiBook is one of the (arguably the) best, and the G4 tower, while not a speed demon, offers the best multiprocessor support in a mainstream desktop. Buy one of them, buy a copy of LinuxPPC, and support the only computer company that still cares about innovation.
Call me a heretic, but I think .net is a good thing. Not .net as made by Microsoft, but .net as an open standard - for example Mono. The concept of making Web services as easy to run and use as regular applications.
.net is simply recognizing the reality that the Internet is a dynamic medium, and it requires a new way of designing programs; a way that makes using the Web identical to using your computer locally. All of the examples I just gave can be done now with existing programming tools on any platform, but .net makes it much easier and more straightforward. It's nothing particularly difficult, and open source will be quick to replicate it.
.net for Apache support, Mono will be ready to take its place.
I don't want to have everything run on a server and use a dumb terminal. No sense making it even easier for Ashcroft to read my stuff than it already is. But Web services, by nature, are things that already use the Internet - things that might as well be hanging on a building in Times Square, for all Ashcroft cares.
To check stocks, I have to go to cnbc.com. It's an ugly interface. Why can't I double-click on a program that uses native widgets and displays that same information? To read and reply to Slashdot, I have to slashdot.org. It's uglier than a female dwarf (or KDE). Why can't I have Slashdot in a Win32-native interface? Think NNTP, but better-looking and more powerful.
To write a document, I open up AbiWord. If I'm writing a story about the stock market, why can't I just open up my stock market program, drag a box into my document, and have live numbers for the Dow? If I'm writing a story about AMD, why can't I just open up my Slashdot program, drag a box into my document, and have a link to the story inserted into my document; and why can't the person on the other end open the document, double-click my link, and have the Slashdot story opened in place - without needing a web browser?
As Miguel de Icaza said, you shouldn't just not use Mono because it's a copy of a MS product - after all, Linux itself is a copy of non-free UNIX from AT&T. If/when the time comes that Microsoft decides to cut off
The Opteron is compatible with all software made since the 8086. Therefore, the Opteron cannot truly be called new technology. It may have evolved in certain ways, but at its core it is no more advanced than the 8086. You can read AMD's whitepaper, and it will confirm: AMD knows that RISC, or specifically VLIW, is faster than CISC, but doesn't want to switch because of the installed base.
Intel, with the Itanium, takes the opposite stance. They know that CISC sucks, and that x86 was doomed from the start. It's not that "new things are better"; VLIW processors could have been developed in 1980, and if they were there would be no need for Itanium. But they didn't. So Intel wants to use 64-bit as an excuse to throw out x86, and start over the way they should have from the beginning.
Let's hope that Intel uses it's 75% marketshare power to win. It'll be unfortunate if AMD does.
Ohh, you're using svgalib. That's an option too. :D My links was compiled with framebuffer support, so I used that instead.
Hmm... I'm guessing the framebuffer device, /dev/fb/0 or /dev/fb0, is set to root-only. Try changing that to have user-accessible permissions; the former if you have devfs, the latter if you don't.
I've got news for you - it's done.
:D But I'll learn. Most of what I'm doing is just removing and rearranging code, anyway.
Ever used links? No, really? For a while now, it's had this really nice option, -g. Load it up, and it'll load links in the framebuffer. Full graphics, no X. It's fine, because the average user can't multitask in real life, let alone on a computer.
If Uncle Joe multitasks, it just means that he has Outlook Express open in the background checking his email while he writes a letter. He'll never have two tasks open in the foreground. Never! Find me a single Windows user who routinely doesn't have all their windows maximised. Sure, every so often they might use 'tile', but that's about it.
The thing is, most people want pretty pictures. So what do you do? Simple. First, make the kernel compilable in single-user-only mode; there can still be Win98-style 'user profiles', but no real system-level multiuser support - that will just confuse users and bloat the system.
Next, load the framebuffer on startup. Hide all boot messages, and insteaad just display a stylized, *huge* penguin (not the one they do now, bigger) in the style of the Windows boot screen.
When it finishes loading, instead of seeing a standard login prompt, the user sees a row of icons on the top of the screen with default apps (mail, browser, word processor), a help button, their chosen background image, and a command prompt. With accelerated framebuffer support, the graphics look as nice as those on Windows. Almost everything a user needs to do, they can do with the default icons, and anything else they can just type in the commands. (The buttons on top are like the ones on the WinXP start panel - after a week or so of use, they become the most common programs the user runs.) If a user needs to multitask, that's what 'screen' is for.
You know, it can't be that hard to do this... now I'm going to try to make a distro with [a] a modified FS, [b] a better package-installing system, and [c] this kind of interface. Except that I can't code.