For an entry level PC used for web/email/word processing and spreadsheets, a PII 400 would be good enough. I'm sure there must be a cheap equivalent from VIA.
Of course Linus owns Linux, so all works with that name appearing on them are derivative works of Linux and thus are also owned by Linus Torvalds. Linuxworld.com now owes Linus $699 per page view for distributing his intellectual property.
>> So you can't tolerate less than the original amount data being sent before retransmit?
> Correct. That is dictated by information theory.
Heh, you have no idea how dumb I feel:) That was the most obvious statement I've made in a long time.
So the thing with the simple scheme the OP showed is that if the network is dropping about one in every three packets, that scheme is better than TCP because TCP has to wait to see exactly *which* packets were dropped, though TCP would be better for a mostly reliable network and fast network, as the article states.
How come we haven't been using such schemes already, especially if the codes can be suited to the current reliability of the network and combined with TCP like behaviour to cope during the window when the network doesn't fit the model?
presumably they would vary quickly between max rate and (2*desired - max), so TCP would act like there was a steady network (ignoring the rapid change). If the max and min rates go okay, add a DC component and reduce the amplitude. If the peaks drop packets, move the DC component down and reduce the amplitude until the peaks don't drop packets, if the troughs also drop packets, reduce the DC component and amplitude further.
But perhaps TCP could benefit from this sort of thing too, start on an expected "good" rate, and oscillate rapidly, adjusting the DC component to increase the average rate, and adjust the amplitude to reduce the retransmit rate.
I suppose the ECC could be sent on a trough to cope better with loss on a peak while the reliability is unknown.
I have not studied this though. It seems very interesting, perhaps I will look into it further.
Did you see the size of the damned thing?! I could fart more pollutants than that thing!
Seriously though, the cluster of generators for the home could pose a problem, as large power stations are pretty good on the pollution front, and they are far away from hot densly populated area's with little air flow such as ground level in urban regions.
If the guy was fired, he must have been project leader, since only the project leader should have approved such a major check-in to the trunk code. If he wasn't the project leader, then the project leader should have been fired. If he had check-in/merge permissions to the trunk due to efficiency requirements (small shop) then the code reviewer should have seen the huge change in the SCM logs and referred it to the project leader for consideration for backing out.
The big thing between natural images and CG is that natural images have "uneven" textures, and the human visual system ignores those textures, provided that they are present in some form close to how they really are. With CG images (unless it is photo-realistic), the human "invents" texture where there is none in order to cope with it. If you add texture by quantising the coefficients of an 8x8 DCT, the added texture is *highly* visible because there is no texture around it (or only very ordered texture). An 8x8 DCT with very different quantisation levels for each coefficient looks chaotic (it may actually be so), so the human can pick out no order, and it looks "natural". The areas around it look unnatural, and the human does not cope well with that.
With white text on a black background such as for credits, this effect is also present. This is because, although the background is typcially "naturally" textured by noise to make it look comfortable on screen, the codec removes this texture due to the low contrast (it is barely noticeable, so "Not Important"TM and, anyway, the human will "invent" it back again), but provides a texture around the text with an unnaturally square boundary between the two.
This invention is why cartoons are pleasing to watch, but near photorealistic CG (especially of human faces) is so disconcerting. The texture is there in the CG, so it is not invented but it is not appropriate for a human face, so as natural xenophobes we become uncomfortable with the face, we do not trust it, or what it says, or the emotions it purports to show.
They probably have a deal with Microsoft not to make WMV look bad so that they can make and distribute derivative works of Microsoft's IP (halo graphic design, etc...).
Seriously, WMV does a very good job with natural content, but that doesn't mean it is any good with CG. Just try compressing a screenshot with JPEG.
Disclaimer, I haven't tried compressing CG with WMV, nor with DivX - so this is purely conjecture.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1, Funny
> VS.net vs Eclipse: no contest, VS.net is much worse.
So you could say that VS.Net has been eclipsed. Heh... Sorry, that was terrible.
I cetainly don't agree with the one comment every three lines. I have a file that I'm particularly proud of implementing a physical memory allocator using a slight variation on the buddy list allocator. It has a block comment at the top of the file detailing the differences from this allocator and the standard buddy list allocator, as well as specifying the invariants. I have one comment within the actual code, marking that a loop termination condition needs checking properly then being put into it's own function/macro. The other comments are all just before each function (which have descriptive names) and mention how/when they should/may be used.
Okay, most of the functions are only 5/6 lines long, but the rule I use for commenting is each separate bit of logic has a comment if the function has non-obvious pre/post-conditions. If you need a comment explaining what some code is *for* or how it *works*, that code should probably be in it's own function (or even file). So the comments, generally, are not muxxed into your code.
I have known several *graduates* that write code like this:
if (a != 'x' && b == 0) {/* if a is not x, and b is zero */
b = 1;/* set b to one */ } else {/* otherwise */
a = 'x';/* set a to x */ }/* end if */
> The fact that it is currently unable to decode video in a meaning manner at normal speed concerns me greatly. This suggests that it's already 10-100x times slower than current generation video codecs.
Until recent optimisations, I haven't been able to decode broadcast resolution video realtime with any theora players. The issue is C/C++ vs vector assembler (ie, SSE/3dNOW) for the main transform.
The DCT has many fast implementations, the Mallet transform doesn't - lifting is one part of that, but the wavelet filters (along with the lifting algorithm) need implementing in assembler.
I admit I am not a Windows developer, but as I understand it, the programmer can specify his own window classes, so the "Button" class is in no way "The Definitive Button". Borland compilers had their own GUI libraries, Java Swing applications don't look quite like Windows ones, so there is no standard widget set for applications running on the Windows GDI (If I am using the name wrong, though... does it only refer to the C API, or to the window system that provides keyboard/mouse/screen multiplexing?)
Firefox has not used it because it has an interface called XUL that does not necessarily limit itself to features easily mappable to the Microsoft widget set.
If you make a web application and deploy it on you existing kiosks using Firefox on Windows, you can expect to move to Firefox on Linux without any user visible change if you start with an XP theme (that is XP in its older meaning "cross-platform").
Also X windows is a peice of software that runs on many kinds of system. There would be no point to even making X if nobody would included it in their OS's because "it has its own widget set instead of the widget set *we* want to ship in our operating system". The old UNIXes shipped with X and CDE and Motif applications - Motif was the "standard" if anything could be called a standard - but it wasn't free, so all the free/open source software developers made their own.
Until you specifically *prohibit* the development of widget sets other than your personally preferred one true widget set, there will be no standard. That means *every* application developer with spare time *must* agree that your "standard" toolkit is the ideal one, otherwise you'll find another, and another. Since Open Source software is driven by desire for software than desire for money, that will not happen until you either ban Open Source, or create a toolkit so well designed and nippy (even on older machines found in the third world) that everybody wants to use it. Not suprisingly, no such toolkit has been designed yet since it is an extremely difficult task and any attempts to do that have failed, Motif hasn't become the one true widget set, Microsoft's widget set hasn't, Athena hasn't, Gtk+ hasn't, QT hasn't, whatever Emacs uses hasn't, whatever XEmacs uses hasn't, etc... One day maybe somebody will come up with one, and every application on the planet will use it no matter which operating system, but until then you will have computer screens with different widget sets on it. No attempt to create a "standard" widget set has succeeded in becoming the only one, so that cannot be a problem with X.
In fact X had a one true standard toolkit called Xt (X Toolkit - wow!), but people came up with new and better ones, so it is no longer the standard. And that was nothing to do with X, people want to create new and better stuff and that will keep on happening. If it weren't the case and people were expected to "just use the standard one" there would be no Linux because "Windows is the standard operating system". In fact, there would be no Windows because "UNIX is the standard operating system", etc. And as you see with Linux, the UNIX design was not scrapped to create the best Operating System out there, it was just reimplemented with some small differences.
I haven't missed any point. Windows GDI doesn't have a native widget set, that's why you see some older applications look different, also the GIMP, and emacs look different to other Windows applications.
X doesn't provide a widget set because it is the part of an operating system that multiplexes access to video hardware and handles mouse/keyboard so that the events can be distributed into each application's sandbox (window) properly without massive slowdown when running over the network.
X doesn't even claim to be a desktop environment, so it doesn't make sense for its specification to declare that a widget set is even needed, let alone specify the "One True Widget Toolkit" with the "One True Feature Set", "One True Look", and "One True Feel".
Firefox has its own widget set, but makes calls into the drawing routines (!) of the dll (or dlls) that implement Microsoft's preffered widget set - and does that only when you have selected the Firefox theme. Other themes (since the firefox toolkit is themeable) do not involve the Microsoft toolkit at all. Notably input is handled by Firefox, so while the developers have made an effort to produce a similar look, it has a different feel in places, and if the Microsoft widgets change in feel (or Microsoft makes the feel themeable, or partially as in GTK) it will feel completely different.
I have yet to hear a good argument against the X Window System. It all appears to be of the form "X was originally designed for old machines running applications across a LAN, so it *can't* be used for anything else." Or "X doesn't have a 'standard' widget toolkit," but no geek operating system will *ever* have a standard toolkit since emacs has one, firefox has one, KDE has one, GNOME has one, etc, and when those apps get ported over for the geeks moving to a system without X, the new system will have no standard toolkit.
If you'd tried using the first version of Linux, you wouldn't think "that Linux came out of Unix[sic]". I don't even think that ESR *ever* said that Linux came out of UNIX. Linux is designed to have a UNIX-similar API, and a similar set of features.
Before you can figure out where Linux came from and how it relates to UNIX, you must become an experienced computer programmer.
You can tell that a book, movie or song is just a copy because you can follow and appreciate stories and language and music, but computer code is too hard for most people, so an "outsider" can't even identify what is specific to one peice of source code rather than being a normal part of the structure of a well-written computer program.
I don't think so, "wet" is a perception of sensory input, to perceive the feel of ice, it must be cold enough that it does not defrost at the surface when you touch it and is not covered in liquid water already. Such ice is sticky.
mostly because it is asyncronous, while most Linux distro's have synchronous bootup.
Notice how when you start Windows Server 2003, it takes ages for some services to come up, but the log -in screen is there quite quickly.
And once you've logged in, starting certain programs is very slow as it becomes serialised waiting for the services to start. It is really only the presentation of a log in screen that is done sooner in the sequence on Windows, rather than time to boot being shorter.
I have seen efforts to create asynchronous init systems for Linux, and it will be interesting to see the results, even if it is not particularly useful.
Slashdot Mirror
> CPU: Athlon 1.33GHz $41
Shit components?!
For an entry level PC used for web/email/word processing and spreadsheets, a PII 400 would be good enough. I'm sure there must be a cheap equivalent from VIA.
How do we know this isn't a trojan ;)
Except that the most visible and eye-catching ad is from Microsoft...
Of course Linus owns Linux, so all works with that name appearing on them are derivative works of Linux and thus are also owned by Linus Torvalds. Linuxworld.com now owes Linus $699 per page view for distributing his intellectual property.
I went to the hearing, and all I got was this lousy staple remover
>> So you can't tolerate less than the original amount data being sent before retransmit?
:) That was the most obvious statement I've made in a long time.
> Correct. That is dictated by information theory.
Heh, you have no idea how dumb I feel
So the thing with the simple scheme the OP showed is that if the network is dropping about one in every three packets, that scheme is better than TCP because TCP has to wait to see exactly *which* packets were dropped, though TCP would be better for a mostly reliable network and fast network, as the article states.
How come we haven't been using such schemes already, especially if the codes can be suited to the current reliability of the network and combined with TCP like behaviour to cope during the window when the network doesn't fit the model?
presumably they would vary quickly between max rate and (2*desired - max), so TCP would act like there was a steady network (ignoring the rapid change). If the max and min rates go okay, add a DC component and reduce the amplitude. If the peaks drop packets, move the DC component down and reduce the amplitude until the peaks don't drop packets, if the troughs also drop packets, reduce the DC component and amplitude further.
But perhaps TCP could benefit from this sort of thing too, start on an expected "good" rate, and oscillate rapidly, adjusting the DC component to increase the average rate, and adjust the amplitude to reduce the retransmit rate.
I suppose the ECC could be sent on a trough to cope better with loss on a peak while the reliability is unknown.
I have not studied this though. It seems very interesting, perhaps I will look into it further.
So you can't tolerate less than the original amount data being sent before retransmit? (2/3 of 3/2 is 1)
Why not just stick with TCP? Because the common flow control algorithms ramp up in the face of latency? Then use a fast-start algorithm.
I think perhaps there is more to this technology than you describe.
Did you see the size of the damned thing?! I could fart more pollutants than that thing!
Seriously though, the cluster of generators for the home could pose a problem, as large power stations are pretty good on the pollution front, and they are far away from hot densly populated area's with little air flow such as ground level in urban regions.
If the guy was fired, he must have been project leader, since only the project leader should have approved such a major check-in to the trunk code. If he wasn't the project leader, then the project leader should have been fired. If he had check-in/merge permissions to the trunk due to efficiency requirements (small shop) then the code reviewer should have seen the huge change in the SCM logs and referred it to the project leader for consideration for backing out.
So was he the project leader?
The big thing between natural images and CG is that natural images have "uneven" textures, and the human visual system ignores those textures, provided that they are present in some form close to how they really are. With CG images (unless it is photo-realistic), the human "invents" texture where there is none in order to cope with it. If you add texture by quantising the coefficients of an 8x8 DCT, the added texture is *highly* visible because there is no texture around it (or only very ordered texture). An 8x8 DCT with very different quantisation levels for each coefficient looks chaotic (it may actually be so), so the human can pick out no order, and it looks "natural". The areas around it look unnatural, and the human does not cope well with that.
With white text on a black background such as for credits, this effect is also present. This is because, although the background is typcially "naturally" textured by noise to make it look comfortable on screen, the codec removes this texture due to the low contrast (it is barely noticeable, so "Not Important"TM and, anyway, the human will "invent" it back again), but provides a texture around the text with an unnaturally square boundary between the two.
This invention is why cartoons are pleasing to watch, but near photorealistic CG (especially of human faces) is so disconcerting. The texture is there in the CG, so it is not invented but it is not appropriate for a human face, so as natural xenophobes we become uncomfortable with the face, we do not trust it, or what it says, or the emotions it purports to show.
They probably have a deal with Microsoft not to make WMV look bad so that they can make and distribute derivative works of Microsoft's IP (halo graphic design, etc...).
Seriously, WMV does a very good job with natural content, but that doesn't mean it is any good with CG. Just try compressing a screenshot with JPEG.
Disclaimer, I haven't tried compressing CG with WMV, nor with DivX - so this is purely conjecture.
> VS.net vs Eclipse: no contest, VS.net is much worse.
So you could say that VS.Net has been eclipsed. Heh... Sorry, that was terrible.
The Dirac codebook:
I cetainly don't agree with the one comment every three lines. I have a file that I'm particularly proud of implementing a physical memory allocator using a slight variation on the buddy list allocator. It has a block comment at the top of the file detailing the differences from this allocator and the standard buddy list allocator, as well as specifying the invariants. I have one comment within the actual code, marking that a loop termination condition needs checking properly then being put into it's own function/macro. The other comments are all just before each function (which have descriptive names) and mention how/when they should/may be used.
/* if a is not x, and b is zero */ /* set b to one */ /* otherwise */ /* set a to x */ /* end if */
Okay, most of the functions are only 5/6 lines long, but the rule I use for commenting is each separate bit of logic has a comment if the function has non-obvious pre/post-conditions. If you need a comment explaining what some code is *for* or how it *works*, that code should probably be in it's own function (or even file). So the comments, generally, are not muxxed into your code.
I have known several *graduates* that write code like this:
if (a != 'x' && b == 0) {
b = 1;
} else {
a = 'x';
}
Gaaahhhh!
> The fact that it is currently unable to decode video in a meaning manner at normal speed concerns me greatly. This suggests that it's already 10-100x times slower than current generation video codecs.
Until recent optimisations, I haven't been able to decode broadcast resolution video realtime with any theora players. The issue is C/C++ vs vector assembler (ie, SSE/3dNOW) for the main transform.
The DCT has many fast implementations, the Mallet transform doesn't - lifting is one part of that, but the wavelet filters (along with the lifting algorithm) need implementing in assembler.
I admit I am not a Windows developer, but as I understand it, the programmer can specify his own window classes, so the "Button" class is in no way "The Definitive Button". Borland compilers had their own GUI libraries, Java Swing applications don't look quite like Windows ones, so there is no standard widget set for applications running on the Windows GDI (If I am using the name wrong, though... does it only refer to the C API, or to the window system that provides keyboard/mouse/screen multiplexing?)
Firefox has not used it because it has an interface called XUL that does not necessarily limit itself to features easily mappable to the Microsoft widget set.
If you make a web application and deploy it on you existing kiosks using Firefox on Windows, you can expect to move to Firefox on Linux without any user visible change if you start with an XP theme (that is XP in its older meaning "cross-platform").
Also X windows is a peice of software that runs on many kinds of system. There would be no point to even making X if nobody would included it in their OS's because "it has its own widget set instead of the widget set *we* want to ship in our operating system". The old UNIXes shipped with X and CDE and Motif applications - Motif was the "standard" if anything could be called a standard - but it wasn't free, so all the free/open source software developers made their own.
Until you specifically *prohibit* the development of widget sets other than your personally preferred one true widget set, there will be no standard. That means *every* application developer with spare time *must* agree that your "standard" toolkit is the ideal one, otherwise you'll find another, and another. Since Open Source software is driven by desire for software than desire for money, that will not happen until you either ban Open Source, or create a toolkit so well designed and nippy (even on older machines found in the third world) that everybody wants to use it. Not suprisingly, no such toolkit has been designed yet since it is an extremely difficult task and any attempts to do that have failed, Motif hasn't become the one true widget set, Microsoft's widget set hasn't, Athena hasn't, Gtk+ hasn't, QT hasn't, whatever Emacs uses hasn't, whatever XEmacs uses hasn't, etc... One day maybe somebody will come up with one, and every application on the planet will use it no matter which operating system, but until then you will have computer screens with different widget sets on it. No attempt to create a "standard" widget set has succeeded in becoming the only one, so that cannot be a problem with X.
In fact X had a one true standard toolkit called Xt (X Toolkit - wow!), but people came up with new and better ones, so it is no longer the standard. And that was nothing to do with X, people want to create new and better stuff and that will keep on happening. If it weren't the case and people were expected to "just use the standard one" there would be no Linux because "Windows is the standard operating system". In fact, there would be no Windows because "UNIX is the standard operating system", etc. And as you see with Linux, the UNIX design was not scrapped to create the best Operating System out there, it was just reimplemented with some small differences.
I haven't missed any point. Windows GDI doesn't have a native widget set, that's why you see some older applications look different, also the GIMP, and emacs look different to other Windows applications.
X doesn't provide a widget set because it is the part of an operating system that multiplexes access to video hardware and handles mouse/keyboard so that the events can be distributed into each application's sandbox (window) properly without massive slowdown when running over the network.
X doesn't even claim to be a desktop environment, so it doesn't make sense for its specification to declare that a widget set is even needed, let alone specify the "One True Widget Toolkit" with the "One True Feature Set", "One True Look", and "One True Feel".
Firefox has its own widget set, but makes calls into the drawing routines (!) of the dll (or dlls) that implement Microsoft's preffered widget set - and does that only when you have selected the Firefox theme. Other themes (since the firefox toolkit is themeable) do not involve the Microsoft toolkit at all. Notably input is handled by Firefox, so while the developers have made an effort to produce a similar look, it has a different feel in places, and if the Microsoft widgets change in feel (or Microsoft makes the feel themeable, or partially as in GTK) it will feel completely different.
I have yet to hear a good argument against the X Window System. It all appears to be of the form "X was originally designed for old machines running applications across a LAN, so it *can't* be used for anything else." Or "X doesn't have a 'standard' widget toolkit," but no geek operating system will *ever* have a standard toolkit since emacs has one, firefox has one, KDE has one, GNOME has one, etc, and when those apps get ported over for the geeks moving to a system without X, the new system will have no standard toolkit.
Okay, but what about the bailiff?
Because his client asked him to and said they'd pay.
If you'd tried using the first version of Linux, you wouldn't think "that Linux came out of Unix[sic]". I don't even think that ESR *ever* said that Linux came out of UNIX. Linux is designed to have a UNIX-similar API, and a similar set of features.
Before you can figure out where Linux came from and how it relates to UNIX, you must become an experienced computer programmer.
You can tell that a book, movie or song is just a copy because you can follow and appreciate stories and language and music, but computer code is too hard for most people, so an "outsider" can't even identify what is specific to one peice of source code rather than being a normal part of the structure of a well-written computer program.
I don't think so, "wet" is a perception of sensory input, to perceive the feel of ice, it must be cold enough that it does not defrost at the surface when you touch it and is not covered in liquid water already. Such ice is sticky.
There are not a billion millimetres in a metre, only a thousand.
a billion millimetres is 1000 km
mostly because it is asyncronous, while most Linux distro's have synchronous bootup.
Notice how when you start Windows Server 2003, it takes ages for some services to come up, but the log -in screen is there quite quickly.
And once you've logged in, starting certain programs is very slow as it becomes serialised waiting for the services to start. It is really only the presentation of a log in screen that is done sooner in the sequence on Windows, rather than time to boot being shorter.
I have seen efforts to create asynchronous init systems for Linux, and it will be interesting to see the results, even if it is not particularly useful.