I bet the folks who live on Jupiter think our solar system only has 4 planets. After all, Earth and Venus aren't so much bigger or different than Pluto or Sedna. Certainly, Earth is closer in size to Pluto than to Jupiter.
People argue so much over where to draw the line between Planet and non-Planet, but everyone seems to take for granted that Earth is a member of the former class.
Are we talking about designing software to run on such a processor, or designing such a processor itself? While I agree that designing a modern processor is much more complex, designing software that runs on such a thing seems quite similar, to me at least.
I agree that simpler is better, when learning/teaching core computer architecture concepts. However, rather than using old computer simulators, I personally prefer Atmel AVR microcontrollers. With a bare minimum of hardware, you can build a miniature computer from scratch and control every bit of the software that goes into it. It's just a good feeling to know that you aren't relying on anyone else's ROM code to do the dirty work. Plus it's an 8-bit RISC processor with 32 general-purpose registers, which is quite nice when you get too lazy for assembly and break out the gcc cross-compiler. =)
Technically, your interpretation of their words is valid. However, since AMD is ALREADY producing plenty of non-solely-PC-market items, such as
* flash memory (they and Atmel more or less 0wn the flash-memory market), * high-throughput ethernet controllers (the 79C976 is WAY too efficient to justify putting in today's average desktop box), and * embedded microcontrollers (the Elan SC520 is pretty much an entire 486 motherboard and processor in one chip),
...it sounds like you're already far more qualified than I am. *grin*
I'm an embedded systems engineer. I dabble here and there with hardware, but I mostly do software. At all levels, but mostly the deeper levels of things. I've done everything from web user-interfaces under Linux, to custom BIOSes and bootloaders, to firmware to drive network adapter's MACs. And all of that so far has been C and assembly, both of which you already know. Space constraints rarely allow me anything more extravagant than that. If I have it available, I'd probably implement any given thing in Perl, but it's all good.
I'm saddened that CV buzzword compliance takes precedence over simply knowing the tools that would allow you to do the job you're prepared to do. The future is a big place, especially the computer industry. Are you seeking something on the applications side of things, on the bare-metal side of things, or where?
As an engineer who definitely tends towards the bare-metal and hardcore embedded end of things, I'm sure I would recommend far different things than a webdesigner or GUI head or SQL jockey would. Though I think embedded devices will play a large part in the future, I'm sure the other subfields will be right there with it.
Networking courses are filled with archaic ideas like ATM which clearly has no future
ATM has no future? You do realize that DSL is nothing but a modulation format to get ATM frames through twisted pair?
(QoS will be implemented on top of TCP/IP).
In my experience, QoS is implemented under IP, never on top of it. DiffServ, for example, makes use of fields in the IP header if needed, but acts on a level between layers 2 and 3. Especially when integrated with MPLS.
Indeed, how would you go about implementing QoS on top of TCP/IP? Build it into HTTP? What about the non-HTTP protocols? What's to keep them from hogging bandwidth and making your ogg stream skip?
I find it strange that you would claim that ATM is better or worse than IP, anyway. They're on different layers of the network stack entirely. ATM is one possible layer 2. Ethernet and PPP are others. IP is one possible layer 3. IPX and IPv6 are others.
And by the way, I don't think networking needs to be exempt from the "if you want to know about something new, get off your ass and learn it yourself" category, either. If I stayed on my ass, I'd never have fun toys like VLAN and PIM-SM to play with... *grin*
Autoconf is a pain, I agree. That's what Automake is for - it does all the work for you. IMHO, the two together create a rather nice build environment, without too much setup hassle.
Pretty much. The difference being that on Linux, you can report bugs you find and they actually get fixed. They don't just ignore bugs for 7 years which have never been fixed.
Another nice thing is that if you release the source for your application, the distro people themselves generally do all the work necessary to get your stuff working. In my experience, the parent question has really been a non-issue.
FreeS/WAN works, kinda, if you don't mind it taking over routing and a couple of other things with it. pipsecd is a lot simpler (just tunnels, and not even dynamic) to set up, for fixed point-to-point links.
If you don't have to interoperate with win32 peers (other than merely routing for them), I'd suggest tinc. A lot easier to deploy than IPSec variants (in my experience), it's quite good security, and the most easily manageable solution I've come across yet, especially for meshes of more than two machines.
Freshmeat has lots of other possibilities, I haven't even tried the majority, let alone all of them. I'm sure you'll find something that suits you're needs, though. =)
I'm not so sure. If your motherboard bites the dust, I'd think the parent Linux kernel is the one likely to crash and burn, since it's the one directly touching the hardware.
But you did not answer my question in regard to whether I need to travel to The Congo. I saw the movie "Congo" and it was very frightening. I would be afraid of the gorillas if I travelled there.
Since many of the more slimey ones like to use open relays, perhaps that could be used to our advantage. A simple script which smelled like an open relay to anyone connecting to it, but in reality only placed messages in a queue for manual confirmation or something, could be used. Make it log everything anyone does to it, including full message contents, source address, traceroute info, whatever would prove useful in the court case. Its a simple variation on the honeypot theme, really.
In fact, I think such a script may actually be worth writing. Hmmm. Does anyone have snort logs or something of the mechanism their probes use, or am I gonna have to write a full SMTP implementation?
Uhh, ipv6 is kinda the point of it anyway. The "Internet2" (also known as the "6Bone") _is_ the global ipv6 test network, after all. IPv6 is all it runs. Around my neck of the woods, its implemented as a mesh of SIT and GRE tunnels, but the backbone runs native.
I wonder how many hops off of this shiny new hardware my poor little ipv6 GRE-tunnel sits...
Not quite. =) I've used those mostly, simply because I've found myself the most comfortable in those for one reason or another. But I've dabbled in lisp (and scheme), python, haskell, smalltalk, ruby, php, pascal, a few assembly languages, and last but not least, befunge.
I've read every Apocalypse, Exegesis and, err, "Synopsis" (why the namechange?) so far. Almost everything I've read so far has seemed like a good idea. I've personally run into quite a few of the exact issues they're attempting to solve with these changes. Regexps are just as problematic as the rest of it, and I agree with the changes. And since they're ensuring reverse compatibility with every aspect (usually via a flag), even if I didn't like a particular aspect, I wouldn't have to use it.
Frankly, I'm looking forward to it. Parrot is nice, and if it weren't for the memory management issues from string-scalar registers, I'd be seriously looking into implementing it in hardware, but its still not too impressive without the Perl6 parser. So I'm waiting patiently, but I feel it'll be well worth it.
The changes may seem like a lot, but far more will actually be staying the same. Perl's already by far the easiest language for me to implement things in (and I've given basically everything a good try), and it seems as if this batch of changes will solve the few remaining rough areas. Except the learning curve - I think BASIC (for initial concepts) and Pike (for C syntax and functional structure) still have it beaten in that area. Still, it's kinda funny how many apparent perl-haters (old perl and new perl) there are, posting to a forum thats, err, written in Perl =)
Yeah, I figured. I was surprised a PHP version existed at all, because you wouldn't want to run such hefty calculations on the server side anyway - make the clients do it. In any case, there is a.exe version available for download, suitable for most compiler-deprived idiots.
The Pi it calculates doesn't seem to have many significant digits... is there any way the algorithm can be reworked to use a BigFloat library or something, for better precision? And perhaps fork off some children to do the actual work, so the load will spread across my MOSIX cluster and SMP boxes? Even if it just used one process per dimensional calculation (one each for 2d, 3d, 4d), the run would have finished in 20min rather than an hour... =)
The benefit with running a server like ntpd is that its always running. It'll run a query once every 5 minutes or so, and rather than just simply resetting your clock, it'll statistically derive the real time accounting for network lag and randomness and all of that. It'll reliably get better-than-a-millisecond accuracy, given a few days of this. Plus, it can use the same mechanism to detect drifts and inaccuracies in your PC's own clock, and tweak the kernel to compensate. Plus, if you have a pool of peer machines, they can help eachother detect drift more quickly (without having to resort to longterm statistical analysis).
For these reasons, I run ntpd on most of my machines, rather than some set-and-exit cron job.
Likewise, how can one possibly compare "high performance" I/O on Linux without using O_NONBLOCK and SIGIO, and possibly even POSIX AIO? =)
I believe the point was trying to compare apples to apples, which is why the same API was used (to the extent possible) on both sides of the pond.
Perhaps the article had a misleading title. On the other hand, don't all benchmarks have the term 'high-performance' in them somewhere?
I actually liked these articles (even though I saw at least one of them before, here)
- it seemed a good test of basic functionality, and as you rightly pointed out, the API they used really is basic. It did a far better job of comparing apples with apples than most comparisons, rather than shooting for some abstract (and uncomparable) "high-level" API, without even indicating how much of a benefit such an interface has over the base-level.
Actually, as a part-time sysadmin, most-time coder, I agree.
The point of this whole thread is to understand what the code does, right? If your code is unclear, you can aid people in reading it through comments and variable names, but if your code structure is easy to understand, then the goal has already been achieved!
Sure, it can be difficult to decide without bias how understandable your code is. Never overestimate the intelligence of the person who will maintain your code. However, to me, thats simply thats another argument for keeping your code structure clear to begin with.
I haven't read the 802.11a spec yet, but I can say that there isn't much "overhead" in 802.11b - you get 5.5Mbps of throughput through an 802.11b network simply because although they advertise 11Mbps, its 11Mbps *half duplex*. Due to the way the polling rounds work, you'll get at most half of the time slices for transmitting your data.
As I said, I haven't read the spec, but I'm told there isn't much difference on the MAC layer, so 802.11a throughput is quite likely chopped in half in the same manner.
For another source of overhead, I'd question how much CPU power it takes to drive the MAC. The Intersil PRISM-II-based cards we have at work are even harder to drive than NE2000 cards - I can get 5.5Mbps of throughput, but it just about pegs my CPU to get it!
...but I'd be quite interested to see a writeup on whether these dynamics applied equally to the usage of various pieces of Free Software. Any ideas? I'm not sure it applies as well... for instance, I've seen some small and great text editors sprout up in the last few years, but I know quite a few people who love and will never give up GNU Emacs. =)
It's awfully handy to have programs that can talk to each other.
I suppose I can see some logic in that. This is why gnome's invented things like Bonobo and libGAL, I suppose (although I'm not too familiar with either, let alone what KDE's come up with).
Which is why such people install the prominently placed everything-officelike-under-the-sun package which depends on and therefore installs everything else. I don't have a problem with an all-encompassing package, I just demand modularity - even the MS Office installer allows you to choose which things should be installed, after all.
I know there are open source PIMs out there. Why they haven't been integrated is beyond me.
Yes, there are. However, out of curiosity, what purpose would integrating them serve? It just seems like a waste of bandwidth to make everyone download pieces they won't use, to me.
A linux distribution should put different pieces in different packages. If you think its more convenient to be able to deploy everything at once, you can create a metapackage named "task-openoffice" which depends on everything else, and just install that.
Slashdot Mirror
I bet the folks who live on Jupiter think our solar system only has 4 planets. After all, Earth and Venus aren't so much bigger or different than Pluto or Sedna. Certainly, Earth is closer in size to Pluto than to Jupiter.
People argue so much over where to draw the line between Planet and non-Planet, but everyone seems to take for granted that Earth is a member of the former class.
Bigots.
Are we talking about designing software to run on such a processor, or designing such a processor itself? While I agree that designing a modern processor is much more complex, designing software that runs on such a thing seems quite similar, to me at least.
I agree that simpler is better, when learning/teaching core computer architecture concepts. However, rather than using old computer simulators, I personally prefer Atmel AVR microcontrollers. With a bare minimum of hardware, you can build a miniature computer from scratch and control every bit of the software that goes into it. It's just a good feeling to know that you aren't relying on anyone else's ROM code to do the dirty work. Plus it's an 8-bit RISC processor with 32 general-purpose registers, which is quite nice when you get too lazy for assembly and break out the gcc cross-compiler. =)
Technically, your interpretation of their words is valid. However, since AMD is ALREADY producing plenty of non-solely-PC-market items, such as
* flash memory (they and Atmel more or less 0wn the flash-memory market),
* high-throughput ethernet controllers (the 79C976 is WAY too efficient to justify putting in today's average desktop box), and
* embedded microcontrollers (the Elan SC520 is pretty much an entire 486 motherboard and processor in one chip),
I tend toward a more pessimistic interpretation.
...it sounds like you're already far more qualified than I am. *grin*
I'm an embedded systems engineer. I dabble here and there with hardware, but I mostly do software. At all levels, but mostly the deeper levels of things. I've done everything from web user-interfaces under Linux, to custom BIOSes and bootloaders, to firmware to drive network adapter's MACs. And all of that so far has been C and assembly, both of which you already know. Space constraints rarely allow me anything more extravagant than that. If I have it available, I'd probably implement any given thing in Perl, but it's all good.
I'm saddened that CV buzzword compliance takes precedence over simply knowing the tools that would allow you to do the job you're prepared to do. The future is a big place, especially the computer industry. Are you seeking something on the applications side of things, on the bare-metal side of things, or where?
As an engineer who definitely tends towards the bare-metal and hardcore embedded end of things, I'm sure I would recommend far different things than a webdesigner or GUI head or SQL jockey would. Though I think embedded devices will play a large part in the future, I'm sure the other subfields will be right there with it.
Networking courses are filled with archaic ideas like ATM which clearly has no future
ATM has no future? You do realize that DSL is nothing but a modulation format to get ATM frames through twisted pair?
(QoS will be implemented on top of TCP/IP).
In my experience, QoS is implemented under IP, never on top of it. DiffServ, for example, makes use of fields in the IP header if needed, but acts on a level between layers 2 and 3. Especially when integrated with MPLS.
Indeed, how would you go about implementing QoS on top of TCP/IP? Build it into HTTP? What about the non-HTTP protocols? What's to keep them from hogging bandwidth and making your ogg stream skip?
I find it strange that you would claim that ATM is better or worse than IP, anyway. They're on different layers of the network stack entirely. ATM is one possible layer 2. Ethernet and PPP are others. IP is one possible layer 3. IPX and IPv6 are others.
And by the way, I don't think networking needs to be exempt from the "if you want to know about something new, get off your ass and learn it yourself" category, either. If I stayed on my ass, I'd never have fun toys like VLAN and PIM-SM to play with... *grin*
Autoconf is a pain, I agree. That's what Automake is for - it does all the work for you. IMHO, the two together create a rather nice build environment, without too much setup hassle.
Pretty much. The difference being that on Linux, you can report bugs you find and they actually get fixed. They don't just ignore bugs for 7 years which have never been fixed.
Another nice thing is that if you release the source for your application, the distro people themselves generally do all the work necessary to get your stuff working. In my experience, the parent question has really been a non-issue.
FreeS/WAN works, kinda, if you don't mind it taking over routing and a couple of other things with it. pipsecd is a lot simpler (just tunnels, and not even dynamic) to set up, for fixed point-to-point links.
If you don't have to interoperate with win32 peers (other than merely routing for them), I'd suggest tinc. A lot easier to deploy than IPSec variants (in my experience), it's quite good security, and the most easily manageable solution I've come across yet, especially for meshes of more than two machines.
Freshmeat has lots of other possibilities, I haven't even tried the majority, let alone all of them. I'm sure you'll find something that suits you're needs, though. =)
I'm not so sure. If your motherboard bites the dust, I'd think the parent Linux kernel is the one likely to crash and burn, since it's the one directly touching the hardware.
But you did not answer my question in regard to whether I need to travel to The Congo. I saw the movie "Congo" and it was very frightening. I would be afraid of the gorillas if I travelled there.
Oh man, that's classic. =)
Since many of the more slimey ones like to use open relays, perhaps that could be used to our advantage. A simple script which smelled like an open relay to anyone connecting to it, but in reality only placed messages in a queue for manual confirmation or something, could be used. Make it log everything anyone does to it, including full message contents, source address, traceroute info, whatever would prove useful in the court case. Its a simple variation on the honeypot theme, really.
In fact, I think such a script may actually be worth writing. Hmmm. Does anyone have snort logs or something of the mechanism their probes use, or am I gonna have to write a full SMTP implementation?
Uhh, ipv6 is kinda the point of it anyway. The "Internet2" (also known as the "6Bone") _is_ the global ipv6 test network, after all. IPv6 is all it runs. Around my neck of the woods, its implemented as a mesh of SIT and GRE tunnels, but the backbone runs native.
I wonder how many hops off of this shiny new hardware my poor little ipv6 GRE-tunnel sits...
Not quite. =) I've used those mostly, simply because I've found myself the most comfortable in those for one reason or another. But I've dabbled in lisp (and scheme), python, haskell, smalltalk, ruby, php, pascal, a few assembly languages, and last but not least, befunge.
I've read every Apocalypse, Exegesis and, err, "Synopsis" (why the namechange?) so far. Almost everything I've read so far has seemed like a good idea. I've personally run into quite a few of the exact issues they're attempting to solve with these changes. Regexps are just as problematic as the rest of it, and I agree with the changes. And since they're ensuring reverse compatibility with every aspect (usually via a flag), even if I didn't like a particular aspect, I wouldn't have to use it.
Frankly, I'm looking forward to it. Parrot is nice, and if it weren't for the memory management issues from string-scalar registers, I'd be seriously looking into implementing it in hardware, but its still not too impressive without the Perl6 parser. So I'm waiting patiently, but I feel it'll be well worth it.
The changes may seem like a lot, but far more will actually be staying the same. Perl's already by far the easiest language for me to implement things in (and I've given basically everything a good try), and it seems as if this batch of changes will solve the few remaining rough areas. Except the learning curve - I think BASIC (for initial concepts) and Pike (for C syntax and functional structure) still have it beaten in that area. Still, it's kinda funny how many apparent perl-haters (old perl and new perl) there are, posting to a forum thats, err, written in Perl =)
Yeah, I figured. I was surprised a PHP version existed at all, because you wouldn't want to run such hefty calculations on the server side anyway - make the clients do it. In any case, there is a .exe version available for download, suitable for most compiler-deprived idiots.
The Pi it calculates doesn't seem to have many significant digits... is there any way the algorithm can be reworked to use a BigFloat library or something, for better precision? And perhaps fork off some children to do the actual work, so the load will spread across my MOSIX cluster and SMP boxes? Even if it just used one process per dimensional calculation (one each for 2d, 3d, 4d), the run would have finished in 20min rather than an hour... =)
Thats because they didn't run the calculation for any real length of time. Behold:
./2d3d4d_1
--[~]--
INPUT
Calculate the Pi for circle, sphere and hypersphere.
Let us start the verification for 2d, 3d and 4d, Give Cycles
Cycles = 100000000000
CIRCLE
Area of circle by brute force method = 78539815867
Radius = 158113.883008
Calculated value of Pi = 3.141593
SPHERE
Volume of sphere by brute force method = 52359877534
Radius = 2320.794417
Calculated value of Pi = 3.141593
HYPERSPHERE
Enclosure of Hypersphere by brute force method = 30842511725
Radius = 281.170663
Calculated value of Pi = 3.141593
The longer it runs for, the closer it gets. Whether or not this actually proves anything is, of course, up to debate.
The benefit with running a server like ntpd is that its always running. It'll run a query once every 5 minutes or so, and rather than just simply resetting your clock, it'll statistically derive the real time accounting for network lag and randomness and all of that. It'll reliably get better-than-a-millisecond accuracy, given a few days of this. Plus, it can use the same mechanism to detect drifts and inaccuracies in your PC's own clock, and tweak the kernel to compensate. Plus, if you have a pool of peer machines, they can help eachother detect drift more quickly (without having to resort to longterm statistical analysis).
For these reasons, I run ntpd on most of my machines, rather than some set-and-exit cron job.
Likewise, how can one possibly compare "high performance" I/O on Linux without using O_NONBLOCK and SIGIO, and possibly even POSIX AIO? =)
I believe the point was trying to compare apples to apples, which is why the same API was used (to the extent possible) on both sides of the pond.
Perhaps the article had a misleading title. On the other hand, don't all benchmarks have the term 'high-performance' in them somewhere?
I actually liked these articles (even though I saw at least one of them before, here) - it seemed a good test of basic functionality, and as you rightly pointed out, the API they used really is basic. It did a far better job of comparing apples with apples than most comparisons, rather than shooting for some abstract (and uncomparable) "high-level" API, without even indicating how much of a benefit such an interface has over the base-level.
Actually, as a part-time sysadmin, most-time coder, I agree.
The point of this whole thread is to understand what the code does, right? If your code is unclear, you can aid people in reading it through comments and variable names, but if your code structure is easy to understand, then the goal has already been achieved!
Sure, it can be difficult to decide without bias how understandable your code is. Never overestimate the intelligence of the person who will maintain your code. However, to me, thats simply thats another argument for keeping your code structure clear to begin with.
I haven't read the 802.11a spec yet, but I can say that there isn't much "overhead" in 802.11b - you get 5.5Mbps of throughput through an 802.11b network simply because although they advertise 11Mbps, its 11Mbps *half duplex*. Due to the way the polling rounds work, you'll get at most half of the time slices for transmitting your data.
As I said, I haven't read the spec, but I'm told there isn't much difference on the MAC layer, so 802.11a throughput is quite likely chopped in half in the same manner.
For another source of overhead, I'd question how much CPU power it takes to drive the MAC. The Intersil PRISM-II-based cards we have at work are even harder to drive than NE2000 cards - I can get 5.5Mbps of throughput, but it just about pegs my CPU to get it!
...but I'd be quite interested to see a writeup on whether these dynamics applied equally to the usage of various pieces of Free Software. Any ideas? I'm not sure it applies as well... for instance, I've seen some small and great text editors sprout up in the last few years, but I know quite a few people who love and will never give up GNU Emacs. =)
It's awfully handy to have programs that can talk to each other.
I suppose I can see some logic in that. This is why gnome's invented things like Bonobo and libGAL, I suppose (although I'm not too familiar with either, let alone what KDE's come up with).
Which is why such people install the prominently placed everything-officelike-under-the-sun package which depends on and therefore installs everything else. I don't have a problem with an all-encompassing package, I just demand modularity - even the MS Office installer allows you to choose which things should be installed, after all.
I know there are open source PIMs out there. Why they haven't been integrated is beyond me.
Yes, there are. However, out of curiosity, what purpose would integrating them serve? It just seems like a waste of bandwidth to make everyone download pieces they won't use, to me.
A linux distribution should put different pieces in different packages. If you think its more convenient to be able to deploy everything at once, you can create a metapackage named "task-openoffice" which depends on everything else, and just install that.