Apparently you don't remember Netscape 4.x's ability to crash at the drop of a hat.
I fail to see where I said or implied that.
I do remember that it was quite crash-prone. I also remember that so was anything on windows at that time, especially internet explorer.
Netscape might have seemed buggy to people who didn't use windows (it's certainly one of the most crash-prone X applications I've ever used), but there was no great stability gap between internet explorer and netscape at that time. In fact, I think the unix versions of netscape were quite a bit buggier than the windows versions.
You mean Mosaic? Mozilla was originally the codename for the rendering engine behind Netscape, which was based on Mosaic.
We have been content to allow the number of 'net clients grow, but why? Why not incorporate these into the browser experience?
Because the usability sucks. Look how unfriendly webmail is to the user. Look at how advanced usenet clients are, compared with discussion forums like slashdot.
Why not support new protocols s they go mainstream, or at least have a way to support plug-ins at this level?
I know you can do this fairly easily with internet explorer and konqueror, I expect you can do it with mozilla as well.
Compare IE v5, v5.5 and v6.0. Nothing much really changed between them. Sure, they cleaned up some of the CSS support (although there are still some large gaps)
Large gaps? Perhaps if you are the kind of person who would describe the Earth as a "large rock".
It leapfrogged over Netscape in features.
That's not the way I remember it. The "new features I remember were channels (ignored by virtually everybody), the ability to embed a page on your desktop (ignored by virtually everybody), and the fact that it was embedded into Windows 98.
And as long as Netscape was stuck on the 4.x codebase, it stayed that way. That code was crap.
Users don't care about the quality of the code. The users were getting sucked up into the MS machine simply because they used the defaults. This could have been avoided, but Netscape went four years or so without a major release.
During that time they were dropped as the default by virtually all ISPs, the only significant source of new users.
During that time, developers started to use CSS, and as less and less people were using Netscape, and as the support for CSS in Netscape 4.x was terrible, websites began to look worse and worse for Netscape users. The quality of Netscape dropped through the floor in terms of what its users were getting out of it.
NS 4.x is dead,
Actually, plenty of people still use it (mostly organisations that standardised on it years back). Netscape 4.8 was released just a few months ago.
IE 4.x is dead
That's the primary benefit (for me) of having IE embedded into the OS. People automatically get newer versions of IE as they upgrade their OS to use all the new applications that come out. It's virtually the only thing that can force a user to upgrade his browser.
the web is growing up and finally truly embracing CSS. And you know who's in the lead? Mozilla, followed by Opera and others, and in last place? IE.
The users don't even know what CSS is. They don't see its effects or IE bugs, because virtually all web authors are force to code workarounds for IE or lose visitors.
Where something works better in other browsers, most visitors won't even know because most users only use one browser.
Fitting all that into 48Kb is astonishing. But aside from memory constraints, there's the issue of raw crunching power. To do what Continki does requires code that gets a lot done in very few cycles. Good and clever algorithms make up a huge part of this.
I agree, with one caveat: efficient code can often be far less elegant than "normal" code. For example, there are plenty of goto statements in the Linux kernel. Using some of the more advanced features of C++ can have an efficiency impact, even if it does result in a simpler, more easily understood architecture.
The problem is, a lot of people fall back to poorly written libraries that may not be as mature as perceived. They're only used because they are convenient.
Yes, but the libraries can be improved or replaced independently of the applications. I believe there is a tiny libc floating around somewhere, for instance.
Oh, and when I was referring to when I said that libraries can bloat an app, consider a configuration file format in xml. Although it may never need to support anything other than us-ascii, use of an xml parser library would include code for unicode support at the very least, when a custom-written parser would not. Hence the trade-off between a well-understood, mature library, and a new, efficient chunk of code specific to that application. This is the kind of thing that would result in different choices for embedded vs desktop constraints.
What's your problem with usability engineers? Usability is a big deal, and it involves a lot of work that differs from normal development quite a bit. Usability enhancements can increase sales and employee efficiency by a hell of a lot.
How about learning a little about the field before dismissing it as a silly title for a developer?
Today's software is written so poorly that super high-end hardware is needed to make up for lazy/poor programmers.
No. The market has determined that programmer brains are far more valuable than cpu cycles. It's cheaper to upgrade a cpu than it is to upgrade a brain.
It's a shame there aren't more developers or at least software architects out there with this guy's talent. We'd all be saving a hell of a lot of money I think.
In all reality, it's probably just that he spent a lot of time on it. Programmer time is expensive to businesses. I'm sure if people were willing to spend more money on software, they could save a little money on hardware.
Good engineering practices don't equate to small code. For example, reuse of existing libraries may increase overall code size compared with something written from scratch, but is usually a better engineering choice, as the libraries can be tested individually, and mature long before use in any particular application.
Yes, I'm talking mainly about desktop computers, which usually requires different constraints for the applications than embedded devices. Don't mix the two up, the skills demonstrated here could apply very well to embedded programming, but they are less useful in a desktop environment.
With them it is simple to do the things I described above and much much more.
Well you only mentioned things that are trivial to do with multiple windows, which is why you got the response you did. How about letting us in on the "much much more" you talk about - is there anything of note that you can do with tabs that you can't do with multiple windows?
Using seperate windows to perform these tasks quickly becomes awkward -- unless you focus on a limited number of web pages and links or read them like a book. Web browsing, while it can be linear, is rarely linear.
Huh? What is the difference between a set of clickable things inside the browser window, and a set of clickable things outside the browser window, apart from with the former I can't use my usual interface to manipulate them?
Perform all of the 4 tasks I've listed above with a tabbed browser...then go and do the same thing without them in the browser of your choice.
I try tabs every now and then. The only time I found it useful is when I was stuck on windows at work. It allowed me to group sets of browser windows. Ordinarily, I would use virtual desktops to do this, which isn't limited to a single application.
You have two separate issues confused - the licensing of the code and its commercial value. Commercial does not imply closed-source, in fact the very toolkit you are talking about (QT) is both open-source and commercial.
Now, it's true that closed-source applications will need to license QT under something other than the GPL/QPL, however there is something that can be done to avoid this - clone QT.
Back before QT was GPLed, there was a project to clone QT, when it was far simpler. It died because nobdy cared enough to put the work in. They didn't care because:
It affected very few people in the community.
Trolltech seem to be very clueful.
If Trolltech turned around and started being unreasonable, they can expect people to care much more about a clone.
For example, he thinks that KDE being "more feature rich" is a good thing. Sorry, but that's not true.
Yes it is. Simplicity is a feature too. Or are you confusing "feature" with "clickable thing" like so many people who argue against "features" do?
And while some users get all pushed out of shape about inconsistent appearances, consistency just isn't a big deal to many users either.
If it isn't a big deal to those people, then they won't mind if everything is consistent then, will they?
Motif and Xaw, for all their many and fatal faults, had better support for remote applications, customization, and inter-application communication than either Gnome or KDE.
Remote applications? That's something built into X, not specific to Motif. Inter-app communication? Like DCOP and MCOP? Like embedding X apps directly into a QT application?
And Gtk+ and Qt both make very inefficient use of the X11 APIs, giving X11 an undeserved reputation for being slow.
Care to give an example? The QT percieved slowness is largely due to slow startup speed, something directly related to the GNU tools used to compile it.
"If on your campus you had an assault and battery or a murder, you'd go down to the district attorney's office and deal with it that way," said Rep. William Jenkins, R-Tenn.
Either someone is taking the mickey, or this politician really needs to get a sense of proportion.
He has the right perspective. It's a federal offense, where simple assault is not, so it's more serious. He's simply responding to that.
It's the law that has the wrong perspective. This shouldn't be a federal offense at all. Is any reasoning behind this Act, or have they done away with that completely, and just consider corporate sponsorship now?
Well I know of at least one small hosting company here in Ireland who do not keep (beyond standard log files they don't touch let alone preserve) these sorts of records for themselves let alone anyone else
SMTP offers no real protection against traffic analysis. Even if you encrypt every email you send, the headers are still sent as plaintext, so you can still monitor who emails who. Even if you use webmail over SSL, the emails still come in through SMTP.
Yes, you can set up your SMTP server to allow access over TLS, however since virtually no ISPs support this, unless the sending party sets up their own SMTP server as well, everything will still be unencrypted. Even if you set up your own servers, connections between the two servers can be tracked.
IE:mac has a ton of problems (slow speed, general bugginess, non-native "feel" under OS 9 OR Jaguar), but you can NOT fault its CSS compliance.
I bloody well can. When 5.5 first came out, it had the best CSS 1 support, and possibly the best CSS 2 support at the time, but that isn't saying much. All browsers have plenty of bugs with CSS. Even the W3C testbed browser, Amaya can't handle a lot of CSS. Essentially, if you care about a certain browser/platform, you have to test with it, regardless of whether you write standards-compliant code or not.
Aside from Safari (still in development and getting better every day), Konqueror (in CVS, much more compliant than even the 3.1 release), and Mozilla, IE:mac has some of the best CSS rendering available on any platform period.
Don't forget Opera. Oh wait. Basically, you are saying apart from every other mainstream browser, Mac IE has some of the best CSS rendering available on any platform. See the problem?
It's one of the few redeeming qualities (if not the only one... hell, it's the only one that I can think of.)
It does a good job of CSS 1, which was brilliant when it first came out. It's certainly in a different league to its Windows counterpart. But you have to recognise that being a minority browser that's impossible to test without investing a decent amount of money puts the onus on its developers to excel, or its users to switch to a better browser, rather than relying on web developers to treat it with kid gloves. You certainly can't accuse developers of being lazy or putting out low-quality work just because their code doesn't work in Mac IE (granted, it may be symptoms of a worse problem, but that's irrelevent to this discussion).
Unfortuantely, a growing number of web designers are incompetent and/or just plain lazy when it comes to building sites that work with browsers other than IE.
There is no excuse for building a site that won't at least provide basic navigation and information with even the simplest of browsers.
It's not just laziness. Most browsers have bugs in their CSS support that cause hideous problems. This includes Mac IE. Unfortunately, Mac IE doesn't work on anything but Macs (and is a completely separate codebase to Win IE), so the average web developer is looking at plonking down hundreds of pounds/dollars/oolas just to make sure their standards-compliant website can render properly in a buggy, minority browser.
If you want buggy browsers that are only used by a minority of people to be well-supported, find a cheaper way of testing in them.
I've found HTTP transfers are a little faster than FTP transfers (just personally, and I can in no way prove it - it may be user error, or just the programs I'm using)
Most probably because of caching, which FTP doesn't support. Even if you use a direct connection to the server, there are transparent proxies, and of course, they can implement caching their end as well, for the case of dynamic content, etc.
Even if the content is uncachable, there is one less DNS lookup (the caching proxy takes care of it, which will probably have a better connection than you and is more likely to have it cached).
There is no clear "Use this" or "Use that" procedure here, it depends entirely on your situation, what you're serving, what your network setup is, etc...
Agreed 100%. The best tip for getting good answers to technical questions is to include as much detail as possible.
Umm, yes, that was my whole point. Did you miss the irony tags? When comparing Open-Source Software to closed source software, OSS is often unfairly accused of being unsupported. This is an example that clearly demonstrates that going with closed-source software that uses a proprietary file-format is the risky option, not OSS, in terms of support.
Slashdot Mirror
I fail to see where I said or implied that.
I do remember that it was quite crash-prone. I also remember that so was anything on windows at that time, especially internet explorer.
Netscape might have seemed buggy to people who didn't use windows (it's certainly one of the most crash-prone X applications I've ever used), but there was no great stability gap between internet explorer and netscape at that time. In fact, I think the unix versions of netscape were quite a bit buggier than the windows versions.
You mean Mosaic? Mozilla was originally the codename for the rendering engine behind Netscape, which was based on Mosaic.
Because the usability sucks. Look how unfriendly webmail is to the user. Look at how advanced usenet clients are, compared with discussion forums like slashdot.
I know you can do this fairly easily with internet explorer and konqueror, I expect you can do it with mozilla as well.
Large gaps? Perhaps if you are the kind of person who would describe the Earth as a "large rock".
That's not the way I remember it. The "new features I remember were channels (ignored by virtually everybody), the ability to embed a page on your desktop (ignored by virtually everybody), and the fact that it was embedded into Windows 98.
Users don't care about the quality of the code. The users were getting sucked up into the MS machine simply because they used the defaults. This could have been avoided, but Netscape went four years or so without a major release.
During that time they were dropped as the default by virtually all ISPs, the only significant source of new users.
During that time, developers started to use CSS, and as less and less people were using Netscape, and as the support for CSS in Netscape 4.x was terrible, websites began to look worse and worse for Netscape users. The quality of Netscape dropped through the floor in terms of what its users were getting out of it.
Actually, plenty of people still use it (mostly organisations that standardised on it years back). Netscape 4.8 was released just a few months ago.
That's the primary benefit (for me) of having IE embedded into the OS. People automatically get newer versions of IE as they upgrade their OS to use all the new applications that come out. It's virtually the only thing that can force a user to upgrade his browser.
The users don't even know what CSS is. They don't see its effects or IE bugs, because virtually all web authors are force to code workarounds for IE or lose visitors.
Where something works better in other browsers, most visitors won't even know because most users only use one browser.
I agree, with one caveat: efficient code can often be far less elegant than "normal" code. For example, there are plenty of goto statements in the Linux kernel. Using some of the more advanced features of C++ can have an efficiency impact, even if it does result in a simpler, more easily understood architecture.
Yes, but the libraries can be improved or replaced independently of the applications. I believe there is a tiny libc floating around somewhere, for instance.
Oh, and when I was referring to when I said that libraries can bloat an app, consider a configuration file format in xml. Although it may never need to support anything other than us-ascii, use of an xml parser library would include code for unicode support at the very least, when a custom-written parser would not. Hence the trade-off between a well-understood, mature library, and a new, efficient chunk of code specific to that application. This is the kind of thing that would result in different choices for embedded vs desktop constraints.
What's your problem with usability engineers? Usability is a big deal, and it involves a lot of work that differs from normal development quite a bit. Usability enhancements can increase sales and employee efficiency by a hell of a lot.
How about learning a little about the field before dismissing it as a silly title for a developer?
No. The market has determined that programmer brains are far more valuable than cpu cycles. It's cheaper to upgrade a cpu than it is to upgrade a brain.
In all reality, it's probably just that he spent a lot of time on it. Programmer time is expensive to businesses. I'm sure if people were willing to spend more money on software, they could save a little money on hardware.
Good engineering practices don't equate to small code. For example, reuse of existing libraries may increase overall code size compared with something written from scratch, but is usually a better engineering choice, as the libraries can be tested individually, and mature long before use in any particular application.
Yes, I'm talking mainly about desktop computers, which usually requires different constraints for the applications than embedded devices. Don't mix the two up, the skills demonstrated here could apply very well to embedded programming, but they are less useful in a desktop environment.
This is already fixed in gentoo:
emerge sync; emerge -u netscape-flashWell you only mentioned things that are trivial to do with multiple windows, which is why you got the response you did. How about letting us in on the "much much more" you talk about - is there anything of note that you can do with tabs that you can't do with multiple windows?
Huh? What is the difference between a set of clickable things inside the browser window, and a set of clickable things outside the browser window, apart from with the former I can't use my usual interface to manipulate them?
I try tabs every now and then. The only time I found it useful is when I was stuck on windows at work. It allowed me to group sets of browser windows. Ordinarily, I would use virtual desktops to do this, which isn't limited to a single application.
Not to mention the all-important "yo".
Why would copyrights be involved? He isn't copying the books, merely listing information about them.
The only way I can see him caring about copyrights is because he is reproducing the cover artwork for some books on the site.
Would that be the Microsoft Shared Source license then? ;)
Of course! Now you can just set up a filter to deny any email that has both of these statements in it:
You have two separate issues confused - the licensing of the code and its commercial value. Commercial does not imply closed-source, in fact the very toolkit you are talking about (QT) is both open-source and commercial.
Now, it's true that closed-source applications will need to license QT under something other than the GPL/QPL, however there is something that can be done to avoid this - clone QT.
Back before QT was GPLed, there was a project to clone QT, when it was far simpler. It died because nobdy cared enough to put the work in. They didn't care because:
If Trolltech turned around and started being unreasonable, they can expect people to care much more about a clone.
Yes it is. Simplicity is a feature too. Or are you confusing "feature" with "clickable thing" like so many people who argue against "features" do?
If it isn't a big deal to those people, then they won't mind if everything is consistent then, will they?
Remote applications? That's something built into X, not specific to Motif. Inter-app communication? Like DCOP and MCOP? Like embedding X apps directly into a QT application?
Care to give an example? The QT percieved slowness is largely due to slow startup speed, something directly related to the GNU tools used to compile it.
He has the right perspective. It's a federal offense, where simple assault is not, so it's more serious. He's simply responding to that.
It's the law that has the wrong perspective. This shouldn't be a federal offense at all. Is any reasoning behind this Act, or have they done away with that completely, and just consider corporate sponsorship now?
SMTP offers no real protection against traffic analysis. Even if you encrypt every email you send, the headers are still sent as plaintext, so you can still monitor who emails who. Even if you use webmail over SSL, the emails still come in through SMTP.
Yes, you can set up your SMTP server to allow access over TLS, however since virtually no ISPs support this, unless the sending party sets up their own SMTP server as well, everything will still be unencrypted. Even if you set up your own servers, connections between the two servers can be tracked.
By "traffic information", I believe they mean data such as who you called/emailed/etc and when, rather than what you actually talked about.
ISP's are in the best position to pursue spammers and demonstrate to courts the financial burden of dealing with spam.
With very few exceptions, we don't hear about ISP's taking spammers to court. What's up with that?
There doesn't seem to be one...
As I recall, Clippy was a (hobbled) product of MS Research.
I bloody well can. When 5.5 first came out, it had the best CSS 1 support, and possibly the best CSS 2 support at the time, but that isn't saying much. All browsers have plenty of bugs with CSS. Even the W3C testbed browser, Amaya can't handle a lot of CSS. Essentially, if you care about a certain browser/platform, you have to test with it, regardless of whether you write standards-compliant code or not.
Don't forget Opera. Oh wait. Basically, you are saying apart from every other mainstream browser, Mac IE has some of the best CSS rendering available on any platform. See the problem?
It does a good job of CSS 1, which was brilliant when it first came out. It's certainly in a different league to its Windows counterpart. But you have to recognise that being a minority browser that's impossible to test without investing a decent amount of money puts the onus on its developers to excel, or its users to switch to a better browser, rather than relying on web developers to treat it with kid gloves. You certainly can't accuse developers of being lazy or putting out low-quality work just because their code doesn't work in Mac IE (granted, it may be symptoms of a worse problem, but that's irrelevent to this discussion).
It's not just laziness. Most browsers have bugs in their CSS support that cause hideous problems. This includes Mac IE. Unfortunately, Mac IE doesn't work on anything but Macs (and is a completely separate codebase to Win IE), so the average web developer is looking at plonking down hundreds of pounds/dollars/oolas just to make sure their standards-compliant website can render properly in a buggy, minority browser.
If you want buggy browsers that are only used by a minority of people to be well-supported, find a cheaper way of testing in them.
Most probably because of caching, which FTP doesn't support. Even if you use a direct connection to the server, there are transparent proxies, and of course, they can implement caching their end as well, for the case of dynamic content, etc.
Even if the content is uncachable, there is one less DNS lookup (the caching proxy takes care of it, which will probably have a better connection than you and is more likely to have it cached).
Agreed 100%. The best tip for getting good answers to technical questions is to include as much detail as possible.
Umm, yes, that was my whole point. Did you miss the irony tags? When comparing Open-Source Software to closed source software, OSS is often unfairly accused of being unsupported. This is an example that clearly demonstrates that going with closed-source software that uses a proprietary file-format is the risky option, not OSS, in terms of support.