You've never seen an actual Windows 2000/XP blue screen, have you? They are different from the old Windows 98/ME blue screens; they don't use text mode any more.
For static content, you do the transform once and cache the result; there's no performance penalty. For dynamically generated content the overhead of doing the XSL is probably going to be pretty small compared to the database lookups or whatever else you're doing to dynamically generate stuff. In many cases you can still use caching anyway. Doing it on the client is unnecessary; the small advantage in a few situations doesn't justify the increase in browser complexity. More complex browsers have more things to break, more ways to be incompatible with other browsers, and won't run well on PDAs or phones. If browsers are going to get more complex, we should get cool new functionality out of it at least, like with SVG. SVG is a million times more useful than client-side XSL.
If you really love XSL, then that's great. You can still use it to make your site more flexible and separate your content, presentation, and navigation, or whatever. But there's no reason to make the browser do it for you. The saved bandwidth is negligable, but the added complexity and processing power needed on the client is large. Do it on the server, just like any other website templating tool does.
Personally, I think that if they added the equivalent of C's #include to HTML (not like iframes but a real include statement that inserts the contents of the second document), that would give you the same bandwidth savings in almost all cases, with no added complexity or godawful syntax. The separation of content and presentation can be done partly with CSS and the rest with a website templating engine or content management system, of which there are billions already that work great. Or you can use server-side XSL if that's what floats your boat. I don't see the any compelling reason to adopt XSL on the client.
Konqueror doesn't let sites hijack your browser the way IE does; that would run contrary to its pragmatic nature. It just wants to do its best to display the site how the designer intended it, within reason. Konqueror allows no popups, no status bar tickers, no window raising/resizing, etc. But changing the color of the scroll bar is quite harmless. Scrollbars are easy to recognize no matter what color they are. They are always in exactly the same place, and they're always exactly the same shape and size. Konqueror doesn't let sites erase the scrollbar by making it black on black or something; it always draws an outline at least. There are no real security or interface issues associated with changing the scrollbar color. It's just an example of the difference in attitude between Mozilla and Konqueror developers.
Except that as I pointed out in my post, it's *NOT* a chicken and egg situation at all, because this is KHTML we're talking about. KHTML has such a teensy market share that whatever it does will not affect web developers in the slightest. The main two browsers (IE and Gecko) already support XSL, and guess what? Nobody uses it anyway.
Personally, I think putting XSL in the browser is retarded. If you really like to construct your HTML from XML using XSL then that's your business, but do it on the server or on your web development machine. That way you control it entirely, there are no browser compatibility issues, and there is less computational load on the client (think cell phones, etc). More complexity in browsers is a bad thing, because every new feature bloats browser code and adds incompatibilities and brokenness. I see no benefits to XSL on the client.
The reason Konqueror doesn't support XSL is that KDE development is pragmatic. KDE developers focus their effort on things that will actually make the browsing experience better today, not complex standards few people like. An example of this pragmatic philosophy is Konqueror's support of the CSS extension that allows you to set scrollbar colors. Mozilla refuses to implement it simply because it's not W3C sanctioned, even though it's a perfectly reasonable CSS extension that is widely used.
KHTML doesn't implement XSL because practically nobody uses XSL. Personally, I doubt it will ever catch on; it's just too complex and the syntax is way too ugly. I haven't seen any compelling reason to use it. If it does catch on, though, you can bet the next release of Konqueror will support it. KHTML developers just don't see the need to waste their time implementing complex standards that nobody wants to use in real webpages. Besides, it's not like KHTML supporting XSL will catapult it into wide acceptance or anything, because KHTML is in a different position than Gecko or IE.
If you want to talk about pathetic, just consider that Mozilla still doesn't support SVG. KDE 3.2 ships with native SVG support. SVG is a well-liked, widely supported standard that is getting a lot of attention and has the potential to change the browsing experience for the better, today. KDE developers realize this, and that's why Konqueror now supports SVG.
I've often wondered what effect Slashdot has had on my writing skills. I post fairly often. When I first got my account I was playing the Karma game, so I went for +5 Funny all the time (it's the easiest to get, just be one of the first few posts and say something mildly amusing). But once I got 50 Karma, getting another +5 post just wasn't that rewarding. Since then I haven't been trying for high ratings, just good discussion.
The moderation system definitely rewards humor. It also rewards clear and concise writing. I think writing tons of Slashdot posts has made my writing more concise. I blame this for my inability to meet page length requirements on my papers. I get right to the point, say everything I want to say in a few pages, and then can't fill the rest up with BS. I also think reading Slashdot has given me a better sense of how to be funny in writing (ignoring IN SOVIET RUSSIA and friends for the moment). I'm constantly looking at failed joke posts and saying "man, that could have been a +5 funny if only he had phrased that differently, or said this extra thing."
Overall, I think Slashdot has given me experience in writing short, clear prose that may be useful in work communication or writing documentation. It hasn't helped with writing 10-page research papers, but once you're out of school nobody cares how many pages you write. I'm interested in what other people think of Slashdot's effect on writing skills. Have you noticed an effect it's had on your writing?
I don't get the point of buttons to close non-current tabs. If you haven't visited a tab yet, it's rare to want to close it. If you are leaving a tab you don't need anymore, you close it while it's still active. If you want to just close all the tabs, you close the window. It's very rare to be browsing one tab and suddenly want to close a specific different one that you visited before without visiting it again. And in the rare case that you do, the context menu allows you to do it quite fast, without waiting for any button to appear, and without any chance of clicking the close button by accident when trying to switch tabs.
I think it would be more useful if the close button appeared on the right side of only the active tab. That way you wouldn't have to wait for it appear, but you still wouldn't accidentally close an inactive tab you were trying to activate, and you still wouldn't have wasted space from a close button appearing on every tab all the time. Having the close button on the actual tab is good because it helps users understand the purpose of the button, but having it on the right is more standard.
Re:Mirror anyone?
on
Review: KDE 3.2
·
· Score: 2, Informative
The parent poster didn't make this clear, but the tabbed browsing in 3.2 is improved *SO* much that going back to 3.1 is painful. When there are too many tabs they now resize smaller instead of doing that stupid scroll-button thingy. There are buttons to close and create tabs right on the tab bar, and the website icon can be turned into a close button if you desire. Dragging a tab lets you drop the URL of that tab anywhere. Middle-clicking the tab bar makes a new tab with the clipboard contents. You can make duplicate tabs (keeping the back button history and everything). In the file manager you can set middle-clicking to open folders in a new tab. Holding the mouse over a tab while dragging switches to that tab (very useful for file management). Somebody on the KDE development team paid a lot of attention to improving tabbed browsing, and it really shows.
Wow, QEMU is improving at an incredible rate! From DOS to Win3.1 to Win98 in four months, and the last release was only a few days ago. Only four times slower than native code (65 times faster than Bochs!), and still getting faster. That's plenty fast to run IE/Word/Outlook/etc on modern processors. At the rate QEMU's improving, they should be able to run WinXP in a couple of months. Once that critical threshold is reached, I think the number of people using QEMU will suddenly skyrocket. I know I'll download it.
I wonder if QEMU could be extended to start running some of the code native, like is suggested in the Plex86 FAQ for Bochs. That way, most of the code woud run at close to 100% of normal speed. Watch out VMWare! You would be able to run Windows under Linux the same way Classic runs under OS X, and it could be included with every Linux distro for free!
Plex86 *used* to be a (future) open-source VMWare alternative. Now, after a long period of basically no development, its goals have been lowered substantially. I think the current plan is to do basically the same things that User Mode Linux already does, just in a slightly different way under the hood so that slightly fewer kernel modifications are required. Plex86 isn't going to be running Windows anytime soon. Disappointing, isn't it.
You laugh. If^H^HWhen you get put on hold at Microsoft Tech support, instead of playing cheesy music they read you soothing Microsoft security bulletins. These security bulletins often contain URLs, so that if you're too stupid to use Windows Update you can still find their patches, or something. If you have never had the pleasure of listening to a cheerful female voice read you a giant URL over the phone, taking about thirty seconds, pronouncing every letter and piece of punctuation separately, but you can't put the phone down because any second now the MS support rep might pick up and say hello, then you should count your lucky stars.
I'm serious, they really read you URLs just like that over the phone, at about 30 seconds per URL. I feel like beating them over the head with a clue bat. Don't they know that the browser adds http:// for you, automatically? Don't they have any idea how to make shorter URLs for easier reading over the phone? And most importantly, don't they have ANY IDEA that security bulletins have ID numbers, specifically so you can reference them easily instead of reading URLs over the phone? Sometimes I wonder about the people at Microsoft...
Yeah, I tried to make the link point to the page with that graph but I didn't realize it didn't work until after I posted:-/
It's an awesome feature, I just wish I knew how accurate it was. I think the traffic for Slashdot may be underestimated because it only counts people who are using the Alexa toolbar for IE. A large portion of Slashdot's readership uses browsers other than IE, so they can't have Alexa toolbar installed. Even the ones using IE are unlikely to have Alexa toolbar, because Slashdotters hate spyware/useless junk on their computers, and they know enough to remove it or not install it in the first place.
Explicit hardware support for overlapping windows is unnecessary. You don't really want the number of windows you can open to be limited by your video hardware, do you? It can be handled easily in software, using video card acceleration features that are standard today. XFree86 still does things the old-fashioned "redraw when windows are exposed" way, but I don't think there's any technical reason why a new X server couldn't keep all contents of all windows in memory at the same time and never redraw due to expose events. In fact I believe Keith Packard's new X server does this to allow neat effects in the style of Mac OS X.
XFree86 is no longer relevant; XFree86.org can go jump off a bridge for all I care. Now there is Xouvert and also Keith Packard's KDrive server at freedesktop.org. Why are they trying to force a license change when they should be fighting for the right to still even exist? If they don't do something, people are going to drop XFree86 in droves and move to freedesktop.org's server for the eye candy alone. As soon as the driver support is there, XFree86 is gone.
Yes, the folks at Ximian are so enamored of monkeys that they made "Build Buddy", a purple bonobo that wants to be your software development friend.
He talks to you!
He can search the Internet for you!
He can write your Makefiles!
He will give you helpful hints on your compile errors!
He can tell jokes!
He will remind you to document your code!
He knows lots of trivia questions about C++ syntax!
Best of all, he's FREE!
Download your very own "Build Buddy" and make a new friend today!
Note for stupid people: the preceeding was entirely made up.
I think that once the migration to the freedesktop.org X server takes place, this kind of problem will be reduced. The more open development model will hopefully allow porting to be done and maintained in the project itself, freeing Debian from having to do it separately. Yet another tangible benefit of the forking of XFree86.
What's broken is the fact that you can do that in the first place. It's thoroughly useless to 99.99% of email users and not even very helpful for the rest (I don't count saving $0.50 on your bandwidth bill as "very helpful"); but it allows forging of email addresses which is a big problem. It wasn't broken back when SMTP was invented and the Internet was full of nice people who cooperated, but it is most definitely broken now. It's not at all like liberating a country by killing everyone, it's more like liberating a country by exiling one person. Definitely worth it.
You missed the point. It's not that *programmers* are overpaid, it's that *Americans* are overpaid. All of us. Or you can look at it as everyone else being underpaid, but it works out the same. We get great perks from being overpaid, such as unrealistically cheap electronics from Asia, but this India thing is poking holes in the dam that's holding up American salaries. As India's economy grows, salaries will go up even in jobs unrelated to outsourcing, prosperity will increase, and cost of living will go up. In the US, salaries may go down, but if it lasts long enough the cost of living will go down too. Eventually the US and the rest of the world will meet somewhere in the middle. I just hope that the changes get over with quickly but aren't too disruptive. Once the process is over, the world economy will be more healthy for it. The Internet may end up erasing the third world/first world divide by making this kind of outsourcing possible and equalizing conditions the world over.
All this is hardly consolation for not being able to find a job, but I'm graduating this year and entering the job market, so I'm in the same boat as most everyone else here.
You don't need to revive XEMO, there is another promising open-source music editing application: Rosegarden. After several false starts, development on it now seems to be proceeding well. They've already had a release this year. I'm sure MusicXML support could be added without too much trouble, if it isn't in there already.
Interesting. I just tried this feature, and unfortunately it completely messed up the layout of the two PDFs I tried it on. However, it did successfully import the text and pictures from both documents. It is unlikely that this feature will let you easily edit and re-save a PDF file, but it could be useful for extracting text and images from them.
KWord's MS Word filters have improved, but they still have a ways to go as well. I tried importing my resume, and found that the import filter doesn't support font embedding, so the layout was different, and the table I used was positioned wrong. I probably won't be using KWord as a.doc file viewer, but I am a fan of its light weight and clean interface. If it proves to be stable enough I may use it for a few documents to see how it fares in real usage.
They can't even get their act together trying to do that with IM clients
They're not trying to do it with IM clients. They just all invent their own incompatible solutions in an attempt to lock everyone in. In email, however, incompatible one-provider solutions aren't feasible because of the existing network. It's a totally different situation. If the spam problem keeps growing at its present rate, big ISPs will be forced to do *something*. I don't think it's inconceivable that they would form a consortium and develop a new email system. It would be simple to make it interoperate with SMTP, but mark SMTP-delivered messages as insecure and likely spam. Later the SMTP migration features could be phased out and suddenly everyone who wants to send mail to the big ISPs needs to use their email system.
Why [change standards]?
You have to ask? The answer is spam.
New standards shouldn't just break existing, *working*, standards.
Once again, SPF doesn't break anything. It is simply a filtering method, one of many which are in use. Secondly, as spam continues to gets worse, you'll have a harder time arguing that SMTP is still a *working* standard. Personally, I would argue that an email system that lets anyone impersonate anyone else is broken on a fundamental level. It just doesn't work on today's Internet.
If you don't like SPF, you don't have to use providers that support it. You just better not complain when you're joe-jobbed.
Slashdot Mirror
You've never seen an actual Windows 2000/XP blue screen, have you? They are different from the old Windows 98/ME blue screens; they don't use text mode any more.
Yeah, they've been working on it since forever ago, and it never seems to get any closer. Wake me when it's in the default install.
For static content, you do the transform once and cache the result; there's no performance penalty. For dynamically generated content the overhead of doing the XSL is probably going to be pretty small compared to the database lookups or whatever else you're doing to dynamically generate stuff. In many cases you can still use caching anyway. Doing it on the client is unnecessary; the small advantage in a few situations doesn't justify the increase in browser complexity. More complex browsers have more things to break, more ways to be incompatible with other browsers, and won't run well on PDAs or phones. If browsers are going to get more complex, we should get cool new functionality out of it at least, like with SVG. SVG is a million times more useful than client-side XSL.
Personally, I think that if they added the equivalent of C's #include to HTML (not like iframes but a real include statement that inserts the contents of the second document), that would give you the same bandwidth savings in almost all cases, with no added complexity or godawful syntax. The separation of content and presentation can be done partly with CSS and the rest with a website templating engine or content management system, of which there are billions already that work great. Or you can use server-side XSL if that's what floats your boat. I don't see the any compelling reason to adopt XSL on the client.
Konqueror doesn't let sites hijack your browser the way IE does; that would run contrary to its pragmatic nature. It just wants to do its best to display the site how the designer intended it, within reason. Konqueror allows no popups, no status bar tickers, no window raising/resizing, etc. But changing the color of the scroll bar is quite harmless. Scrollbars are easy to recognize no matter what color they are. They are always in exactly the same place, and they're always exactly the same shape and size. Konqueror doesn't let sites erase the scrollbar by making it black on black or something; it always draws an outline at least. There are no real security or interface issues associated with changing the scrollbar color. It's just an example of the difference in attitude between Mozilla and Konqueror developers.
Personally, I think putting XSL in the browser is retarded. If you really like to construct your HTML from XML using XSL then that's your business, but do it on the server or on your web development machine. That way you control it entirely, there are no browser compatibility issues, and there is less computational load on the client (think cell phones, etc). More complexity in browsers is a bad thing, because every new feature bloats browser code and adds incompatibilities and brokenness. I see no benefits to XSL on the client.
KHTML doesn't implement XSL because practically nobody uses XSL. Personally, I doubt it will ever catch on; it's just too complex and the syntax is way too ugly. I haven't seen any compelling reason to use it. If it does catch on, though, you can bet the next release of Konqueror will support it. KHTML developers just don't see the need to waste their time implementing complex standards that nobody wants to use in real webpages. Besides, it's not like KHTML supporting XSL will catapult it into wide acceptance or anything, because KHTML is in a different position than Gecko or IE.
If you want to talk about pathetic, just consider that Mozilla still doesn't support SVG. KDE 3.2 ships with native SVG support. SVG is a well-liked, widely supported standard that is getting a lot of attention and has the potential to change the browsing experience for the better, today. KDE developers realize this, and that's why Konqueror now supports SVG.
The moderation system definitely rewards humor. It also rewards clear and concise writing. I think writing tons of Slashdot posts has made my writing more concise. I blame this for my inability to meet page length requirements on my papers. I get right to the point, say everything I want to say in a few pages, and then can't fill the rest up with BS. I also think reading Slashdot has given me a better sense of how to be funny in writing (ignoring IN SOVIET RUSSIA and friends for the moment). I'm constantly looking at failed joke posts and saying "man, that could have been a +5 funny if only he had phrased that differently, or said this extra thing."
Overall, I think Slashdot has given me experience in writing short, clear prose that may be useful in work communication or writing documentation. It hasn't helped with writing 10-page research papers, but once you're out of school nobody cares how many pages you write. I'm interested in what other people think of Slashdot's effect on writing skills. Have you noticed an effect it's had on your writing?
I don't get the point of buttons to close non-current tabs. If you haven't visited a tab yet, it's rare to want to close it. If you are leaving a tab you don't need anymore, you close it while it's still active. If you want to just close all the tabs, you close the window. It's very rare to be browsing one tab and suddenly want to close a specific different one that you visited before without visiting it again. And in the rare case that you do, the context menu allows you to do it quite fast, without waiting for any button to appear, and without any chance of clicking the close button by accident when trying to switch tabs.
I think it would be more useful if the close button appeared on the right side of only the active tab. That way you wouldn't have to wait for it appear, but you still wouldn't accidentally close an inactive tab you were trying to activate, and you still wouldn't have wasted space from a close button appearing on every tab all the time. Having the close button on the actual tab is good because it helps users understand the purpose of the button, but having it on the right is more standard.
The parent poster didn't make this clear, but the tabbed browsing in 3.2 is improved *SO* much that going back to 3.1 is painful. When there are too many tabs they now resize smaller instead of doing that stupid scroll-button thingy. There are buttons to close and create tabs right on the tab bar, and the website icon can be turned into a close button if you desire. Dragging a tab lets you drop the URL of that tab anywhere. Middle-clicking the tab bar makes a new tab with the clipboard contents. You can make duplicate tabs (keeping the back button history and everything). In the file manager you can set middle-clicking to open folders in a new tab. Holding the mouse over a tab while dragging switches to that tab (very useful for file management). Somebody on the KDE development team paid a lot of attention to improving tabbed browsing, and it really shows.
I wonder if QEMU could be extended to start running some of the code native, like is suggested in the Plex86 FAQ for Bochs. That way, most of the code woud run at close to 100% of normal speed. Watch out VMWare! You would be able to run Windows under Linux the same way Classic runs under OS X, and it could be included with every Linux distro for free!
Plex86 *used* to be a (future) open-source VMWare alternative. Now, after a long period of basically no development, its goals have been lowered substantially. I think the current plan is to do basically the same things that User Mode Linux already does, just in a slightly different way under the hood so that slightly fewer kernel modifications are required. Plex86 isn't going to be running Windows anytime soon. Disappointing, isn't it.
"aich-tee-tee-pee-colon-forward-slash-forward- slash-double-U-double-U-double-U-Microsoft-dot- com-forward-slash-default-dot-ay-ess-pee-ex- question-mark-ess-cee-eye-dee-equals-sign-kay- bee-semicolon-seven-three-nine-four-four"
I'm serious, they really read you URLs just like that over the phone, at about 30 seconds per URL. I feel like beating them over the head with a clue bat. Don't they know that the browser adds http:// for you, automatically? Don't they have any idea how to make shorter URLs for easier reading over the phone? And most importantly, don't they have ANY IDEA that security bulletins have ID numbers, specifically so you can reference them easily instead of reading URLs over the phone? Sometimes I wonder about the people at Microsoft...
It's an awesome feature, I just wish I knew how accurate it was. I think the traffic for Slashdot may be underestimated because it only counts people who are using the Alexa toolbar for IE. A large portion of Slashdot's readership uses browsers other than IE, so they can't have Alexa toolbar installed. Even the ones using IE are unlikely to have Alexa toolbar, because Slashdotters hate spyware/useless junk on their computers, and they know enough to remove it or not install it in the first place.
Explicit hardware support for overlapping windows is unnecessary. You don't really want the number of windows you can open to be limited by your video hardware, do you? It can be handled easily in software, using video card acceleration features that are standard today. XFree86 still does things the old-fashioned "redraw when windows are exposed" way, but I don't think there's any technical reason why a new X server couldn't keep all contents of all windows in memory at the same time and never redraw due to expose events. In fact I believe Keith Packard's new X server does this to allow neat effects in the style of Mac OS X.
XFree86 is no longer relevant; XFree86.org can go jump off a bridge for all I care. Now there is Xouvert and also Keith Packard's KDrive server at freedesktop.org. Why are they trying to force a license change when they should be fighting for the right to still even exist? If they don't do something, people are going to drop XFree86 in droves and move to freedesktop.org's server for the eye candy alone. As soon as the driver support is there, XFree86 is gone.
He talks to you!
He can search the Internet for you!
He can write your Makefiles!
He will give you helpful hints on your compile errors!
He can tell jokes!
He will remind you to document your code!
He knows lots of trivia questions about C++ syntax!
Best of all, he's FREE!
Download your very own "Build Buddy" and make a new friend today!
Note for stupid people: the preceeding was entirely made up.
I think that once the migration to the freedesktop.org X server takes place, this kind of problem will be reduced. The more open development model will hopefully allow porting to be done and maintained in the project itself, freeing Debian from having to do it separately. Yet another tangible benefit of the forking of XFree86.
What's broken is the fact that you can do that in the first place. It's thoroughly useless to 99.99% of email users and not even very helpful for the rest (I don't count saving $0.50 on your bandwidth bill as "very helpful"); but it allows forging of email addresses which is a big problem. It wasn't broken back when SMTP was invented and the Internet was full of nice people who cooperated, but it is most definitely broken now. It's not at all like liberating a country by killing everyone, it's more like liberating a country by exiling one person. Definitely worth it.
All this is hardly consolation for not being able to find a job, but I'm graduating this year and entering the job market, so I'm in the same boat as most everyone else here.
You don't need to revive XEMO, there is another promising open-source music editing application: Rosegarden. After several false starts, development on it now seems to be proceeding well. They've already had a release this year. I'm sure MusicXML support could be added without too much trouble, if it isn't in there already.
KWord's MS Word filters have improved, but they still have a ways to go as well. I tried importing my resume, and found that the import filter doesn't support font embedding, so the layout was different, and the table I used was positioned wrong. I probably won't be using KWord as a .doc file viewer, but I am a fan of its light weight and clean interface. If it proves to be stable enough I may use it for a few documents to see how it fares in real usage.
They're not trying to do it with IM clients. They just all invent their own incompatible solutions in an attempt to lock everyone in. In email, however, incompatible one-provider solutions aren't feasible because of the existing network. It's a totally different situation. If the spam problem keeps growing at its present rate, big ISPs will be forced to do *something*. I don't think it's inconceivable that they would form a consortium and develop a new email system. It would be simple to make it interoperate with SMTP, but mark SMTP-delivered messages as insecure and likely spam. Later the SMTP migration features could be phased out and suddenly everyone who wants to send mail to the big ISPs needs to use their email system.
Why [change standards]?
You have to ask? The answer is spam.
New standards shouldn't just break existing, *working*, standards.
Once again, SPF doesn't break anything. It is simply a filtering method, one of many which are in use. Secondly, as spam continues to gets worse, you'll have a harder time arguing that SMTP is still a *working* standard. Personally, I would argue that an email system that lets anyone impersonate anyone else is broken on a fundamental level. It just doesn't work on today's Internet.
If you don't like SPF, you don't have to use providers that support it. You just better not complain when you're joe-jobbed.