So when you're watching your HD video on your Atom 1.6Ghz with NVidia Graphics, what do you use the other free 90% of the CPU for?
How much more do you have to pay to have a freed up 90% CPU that you're probably not using for anything else at the time?
It seems to me you're in a race to the bottom - how much can you spend to use less of what you've paid for. IOW, your goal seems to be to get less bangs per buck, not more.
No offence intended to him, but he's just re-interating the sort of commentary on commenting that's in Code Complete, The Practice of Programming, Linux kernel CodingStyle etc. He's not offering any original insights, or telling war stories that people can learn from. Any decent programmer would already know these myths, and if they didn't, they really should be reading books such as the ones I've listed, not a blog entry with very little original content.
IOW, what makes special enough to be Slashdot front page news?
Surely everybody on Slashdot is old enough to remember 386s? What about 286s? I even remember a 186... It scared me that where I worked recently with a lot of Gen Y's, some of them may not have ever used a single-tasking OS like MS-DOS or CPM.
as per RFCs 1001 and 1002 for TCP/IP and somewhere else for IPX (IPX packet type 20 IIRC). However, if you ran it over "NetBEUI" or NetBIOS Extended User Interface, rather than IPX or TCP/IP, NetBIOS was running directly over 802.2/LLC i.e. no layer 3 protocol in there, so no routing. I think Microsoft removed this option a number of years ago, which is a shame, because that was a way of ensuring that there was no chance your NetBIOS file and print shares were accessible over the Internet.
Appletalk Name Binding Protocol (NBP) is also likely to be vulernable, as is Novell's Service Advertising Protocol (SAP), was well as Multicast DNS (sort-of-aka Avahi, Zeroconf, Bonjour). At the end of the day, you can't completely trust what somebody else says unless you already explicitly trust them.
"The fact is, people dont want to wait years for someone to back engineer some piece of hardware and the idea that hardware companies will provide the specs is unrealistic idealism, even with specs it can be months after Windows users have been able to use the hardware."
Unrealistic idealism? How do you explain the 5618.c files (which we'll be conservative and assume only supports one hardware device each - unlike the realtiy where there are drivers that support many different hardware revsions e.g. the e1000e driver supports *all* 1Gbps Intel PCI-E cards) in the Linux 2.6.31 drivers directory? How do you think the came about? The Linux driver tooth fairy?
For any sort of medium to large network, you can't fully simulate it. That means you're always going to be making "untested" environment. So, you make very few changes rather than lots, you make sure after each change they've had the desired effect, and you have backout plans.
"This is a completely terrible answer, 'get a new ISP' doesn't cut it when I'm one of the fastest and most reliable in the country."
Up until 3 weeks ago I worked at Adam Internet in Adelaide, one of the top 10 ISPs in Australia (and Adam are *only* in South Australia). I had some involvement in the installation of a >0.5 Gbps link from Adelaide to NSW, which was carrying all of their Youtube traffic. IMNSO, based on my experience of Adam Internet's youtube performance from the NSW Pipe Networks PoP, if you're getting quite a lot of buffering on Youtube videos, then you aren't on one of the fastest and most reliable ISPs in the country.
Google have a youtube cache in Pipe Networks NSWs Point of Presence, so if you have an ISP who's connected to that, and makes sure they have enough bandwidth to it, there'll usually be not buffering (on rare occasions there can be, however that is youtube itself)
I think people think linux is "unreliable" because they don't attribute lockups to their binary video card drivers. I've been using Linux as my main OS at home since late 1992, and have run my home PC 24x7 since 2000, and can only remember one kernel panic in all that time - but then again, I've never run a binary kernel module. If you think it is normal to run 3rd party drivers, because you're used to that from the Windows word, and then you do so under Linux, and Linux fails, you're unlikely to attribute the failure to the binary module and the risks of running one, but to Linux itself.
The only thing the GFX card communicates with is the northbridge, which hands off to the CPU, and (possibly) other graphics cards. No other compenents matter for support purposes.
I think you're being dillusional. Nearly every device in a PC needs a driver, and they're typically written by many different parties. The bluetooth wireless keyboard driver could have just as much impact on the Nvidia PhysX device driver as an ATI video driver. Unless the ATI driver is trying to talk directly to the PhysX device, and I doubt it, then this is purely Nvidia restricting customer choice for their own gain.
ility. It runs on more architectures than OpenBSD, and you're saying it's far less portable, and that the architectual differences are exposed? Way back in 2000 I ran (Debian) Linux on a Sun Ultra 5, and it just worked. The only issue I had was nmap, and that was likely due to a missing htonX() calls. OpenBSD wouldn't have magically put those instructions in the nmap code if they didn't exist either.
I've written networking kernel code for Linux, and never encountered any CPU specific requirements - it's all abstracted behind function calls.
Firstly, "in theory, practice and theory are the same, in practice they're not." You'll learn from the process of implementing it, and if you provide your code (and a reasonable number of comments), what you've leaned will be available to other people who read your code.
Secondly, with the right licence, e.g. GPL, corporations won't (or shouldn't be able to) steal your code. If they do, you have legal grounds to sue them.
I don't know the architecture of the ATI/Nvidia GPUs, however from what I understand of the Cell CPUs they might be fairly dfferent with their SPEs. You may encounter problems and develop solutions for them that nobody else will develop. Even better, because your code will be open source, you'll also be open publishing the solution.
Competition is good, but competition relies on competitors. If everybody gave up because somebody else had done it, the world wouldn't be anywhere near as advanced as it is - and the Olympic games would be boring, because there'd only ever be one "competitor" in any race.
"There's a good proof of concept Linux that's run on a T2000, but how many years, how many staff and how many debates on LKML would it take to get from a POC to something you could bet your company on?"
isn't this contrary to what you've now said?
"I know they did the port, and it clearly works, but I'd suggest it is the kind of low-priority thing one does to make sure they have a presence in the machine room, and predominantly on the Sun x86 machines they mentioned in the cited page. "
A low priority port (that they've certified for certain releases), which I wouldn't necessarily disagree with, is a long way from a supposed P.O.C. that nobody would be willing to put any money behind.
I work for an ISP in Australia, we and a number of other local ISPs have local Akamai clusters. I haven't RTFA, mainly because if the summary isn't right, then the article probably isn't right either.
It is mutually beneficial for content providers and ISPs to host content locally. For the content provider, they have more content distribution points, which is a selling point to use with their customers. For the ISP, it shifts typically fairly large amounts and "types" of traffic off of their Internet transit links, saving them money.
Seems you might be criticising him for lack of research when you haven't done any yourself. I suggest you read this thread that recently occurred on the NANOG mailing list -
Slashdot Mirror
So when you're watching your HD video on your Atom 1.6Ghz with NVidia Graphics, what do you use the other free 90% of the CPU for?
How much more do you have to pay to have a freed up 90% CPU that you're probably not using for anything else at the time?
It seems to me you're in a race to the bottom - how much can you spend to use less of what you've paid for. IOW, your goal seems to be to get less bangs per buck, not more.
Helping solve the problem is much harder.
Are you part of the problem, or part of the solution? If all you're willing to do is criticise, then I think you're part of the problem.
It's New Year's Day. What did you want – "Y2K bug still not here"?
That'd have been more original :-)
Here's his bio - still nothing that shows that his insights are exceptional, or supported by years and years of experience or practice.
http://jasonmbaker.wordpress.com/about-me/
No offence intended to him, but he's just re-interating the sort of commentary on commenting that's in Code Complete, The Practice of Programming, Linux kernel CodingStyle etc. He's not offering any original insights, or telling war stories that people can learn from. Any decent programmer would already know these myths, and if they didn't, they really should be reading books such as the ones I've listed, not a blog entry with very little original content.
IOW, what makes special enough to be Slashdot front page news?
Surely everybody on Slashdot is old enough to remember 386s? What about 286s? I even remember a 186 ... It scared me that where I worked recently with a lot of Gen Y's, some of them may not have ever used a single-tasking OS like MS-DOS or CPM.
as per RFCs 1001 and 1002 for TCP/IP and somewhere else for IPX (IPX packet type 20 IIRC). However, if you ran it over "NetBEUI" or NetBIOS Extended User Interface, rather than IPX or TCP/IP, NetBIOS was running directly over 802.2/LLC i.e. no layer 3 protocol in there, so no routing. I think Microsoft removed this option a number of years ago, which is a shame, because that was a way of ensuring that there was no chance your NetBIOS file and print shares were accessible over the Internet.
server address (127.0.0.1) is likely to be a reasonable mitigation.
Appletalk Name Binding Protocol (NBP) is also likely to be vulernable, as is Novell's Service Advertising Protocol (SAP), was well as Multicast DNS (sort-of-aka Avahi, Zeroconf, Bonjour). At the end of the day, you can't completely trust what somebody else says unless you already explicitly trust them.
"The fact is, people dont want to wait years for someone to back engineer some piece of hardware and the idea that hardware companies will provide the specs is unrealistic idealism, even with specs it can be months after Windows users have been able to use the hardware."
Unrealistic idealism? How do you explain the 5618 .c files (which we'll be conservative and assume only supports one hardware device each - unlike the realtiy where there are drivers that support many different hardware revsions e.g. the e1000e driver supports *all* 1Gbps Intel PCI-E cards) in the Linux 2.6.31 drivers directory? How do you think the came about? The Linux driver tooth fairy?
For any sort of medium to large network, you can't fully simulate it. That means you're always going to be making "untested" environment. So, you make very few changes rather than lots, you make sure after each change they've had the desired effect, and you have backout plans.
$ uptime
17:04:37 up 3 days, 7:03, 0 users, load average: 0.04, 0.06, 0.01
$ cpufreq-info | grep "cpufreq stats"
cpufreq stats: 2.40 GHz:1.97%, 2.13 GHz:0.03%, 1.87 GHz:0.04%, 1.60 GHz:97.97% (302491)
cpufreq stats: 2.40 GHz:2.11%, 2.13 GHz:0.02%, 1.87 GHz:0.03%, 1.60 GHz:97.84% (254077)
cpufreq stats: 2.40 GHz:2.18%, 2.13 GHz:0.02%, 1.87 GHz:0.02%, 1.60 GHz:97.78% (203704)
cpufreq stats: 2.40 GHz:1.15%, 2.13 GHz:0.01%, 1.87 GHz:0.01%, 1.60 GHz:98.83% (118501)
$
(load the 'cpufreq_stats' module to have the cpufreq-info utility display these stats)
"This is a completely terrible answer, 'get a new ISP' doesn't cut it when I'm one of the fastest and most reliable in the country." Up until 3 weeks ago I worked at Adam Internet in Adelaide, one of the top 10 ISPs in Australia (and Adam are *only* in South Australia). I had some involvement in the installation of a >0.5 Gbps link from Adelaide to NSW, which was carrying all of their Youtube traffic. IMNSO, based on my experience of Adam Internet's youtube performance from the NSW Pipe Networks PoP, if you're getting quite a lot of buffering on Youtube videos, then you aren't on one of the fastest and most reliable ISPs in the country.
Google have a youtube cache in Pipe Networks NSWs Point of Presence, so if you have an ISP who's connected to that, and makes sure they have enough bandwidth to it, there'll usually be not buffering (on rare occasions there can be, however that is youtube itself)
Start by reading the GPL to find out what your obligations are.
I think people think linux is "unreliable" because they don't attribute lockups to their binary video card drivers. I've been using Linux as my main OS at home since late 1992, and have run my home PC 24x7 since 2000, and can only remember one kernel panic in all that time - but then again, I've never run a binary kernel module. If you think it is normal to run 3rd party drivers, because you're used to that from the Windows word, and then you do so under Linux, and Linux fails, you're unlikely to attribute the failure to the binary module and the risks of running one, but to Linux itself.
The only thing the GFX card communicates with is the northbridge, which hands off to the CPU, and (possibly) other graphics cards. No other compenents matter for support purposes.
I think you're being dillusional. Nearly every device in a PC needs a driver, and they're typically written by many different parties. The bluetooth wireless keyboard driver could have just as much impact on the Nvidia PhysX device driver as an ATI video driver. Unless the ATI driver is trying to talk directly to the PhysX device, and I doubt it, then this is purely Nvidia restricting customer choice for their own gain.
So would supporting people with non-Nvidia keyboards, cases, HDDs, motherboards etc. ... (get the point?)
I've written networking kernel code for Linux, and never encountered any CPU specific requirements - it's all abstracted behind function calls.
Firstly, "in theory, practice and theory are the same, in practice they're not." You'll learn from the process of implementing it, and if you provide your code (and a reasonable number of comments), what you've leaned will be available to other people who read your code.
Secondly, with the right licence, e.g. GPL, corporations won't (or shouldn't be able to) steal your code. If they do, you have legal grounds to sue them.
I don't know the architecture of the ATI/Nvidia GPUs, however from what I understand of the Cell CPUs they might be fairly dfferent with their SPEs. You may encounter problems and develop solutions for them that nobody else will develop. Even better, because your code will be open source, you'll also be open publishing the solution.
Competition is good, but competition relies on competitors. If everybody gave up because somebody else had done it, the world wouldn't be anywhere near as advanced as it is - and the Olympic games would be boring, because there'd only ever be one "competitor" in any race.
"There's a good proof of concept Linux that's run on a T2000, but how many years, how many staff and how many debates on LKML would it take to get from a POC to something you could bet your company on?"
isn't this contrary to what you've now said?
"I know they did the port, and it clearly works, but I'd suggest it is the kind of low-priority thing one does to make sure they have a presence in the machine room, and predominantly on the Sun x86 machines they mentioned in the cited page. "
A low priority port (that they've certified for certain releases), which I wouldn't necessarily disagree with, is a long way from a supposed P.O.C. that nobody would be willing to put any money behind.
http://www.ubuntu.com/partners/sun
I work for an ISP in Australia, we and a number of other local ISPs have local Akamai clusters. I haven't RTFA, mainly because if the summary isn't right, then the article probably isn't right either. It is mutually beneficial for content providers and ISPs to host content locally. For the content provider, they have more content distribution points, which is a selling point to use with their customers. For the ISP, it shifts typically fairly large amounts and "types" of traffic off of their Internet transit links, saving them money.
Vulnerabilities of Network Control Protocols: An Example, published in January 1981.
What do they say about those who ignore history?
Seems you might be criticising him for lack of research when you haven't done any yourself. I suggest you read this thread that recently occurred on the NANOG mailing list -
Network end users to pull down 2 gigabytes a day, continuously?