Again, i'm not sure on most major ISPs, but I used to be an admin for a smaller ISP, and our Cisco 5200/5300 access servers (primarily set up for V.90 56K) would accept ISDN calls just fine, and run 64kb (per B channel) digital/digital connections just fine.
May be worth a shot just asking them, as their equipment quite possibly supports both call types - i'd hazard a guess that it's more an accounting issue than a technical one...
All of my hardware is supported by FreeBSD. USB support worked in the BSDs before it did in linux. The driver "problem" is largely a non-issue. FreeBSD can actually use Windows NDIS drivers for NICs as well...
Pretty sure it was the pentium that started using the Risc core... and yeah, from my limited x86 assembly coding experience (a few half-assed games using inline assembly for quick VGA graphics back in the early-mid 90s) it's definately "strange":)
I was so hoping for the ppc/alpha to take off myself, but alas... "worse is better" strikes again...
It's getting to the point now though that for 99.99% of the coders out there, they couldn't give a crap what a cpu is like to program from an assembly point of view, as most of them wouldn't go any lower level than C these days anyway - most of them won't even go that low...
Linux (or more specifically, "GNU" or "the gnu toolchain") is nothing like 'real' unix when you get further than a cursory observation. The GNU tools are usually different in some subtle way for no *really* good reason (it seems) other than to follow GNU's own "standards".
Examples that spring to mind for example: netstat, ifconfig, info, etc...
If you've used a few flavours of Unix (myself, Solaris, SCO (yes, it sucks), AIX, FreeBSD) the differences (even subtle ones like the display formatting of various commands) in Linux really stand out.
Oh don't get me wrong, I don't call it "GNU/Linux" and I agree it's ridiculous really.
However, calling the operating system "Linux" is not really being truthful either.
There's a lack of a term for describing what it really is ("Linux kernel + free stuff" doesn't have much of a ring to it:D), unless you use a distribution name, i.e., Redhat or Debian, etc.
And you're being very short-sighted about other architectures.
Yes and no.
I'm aware of the embedded space, but personally I think that within a few years it will all be x86 anyway (much as it's a "crappy" architecture). Also, given that the costs of storage, RAM, etc are dropping extremely quickly, I don't think that worrying about 20mb vs 200-600mb is worth wasting the development time on any more.
I still read amusing little pro-Linux rants that are actually just pro-open source Unix userland, not pro-Linux as they believe themselves to be. Don't get me wrong, there are definite differentiators between BSD, Linux, running GNU tools on Solaris, OS X etc. but that's not the point I'm interested in here. For this discussion, I'm interested in seeing many of Unix per-se's benefits being described as Linux benefits when they are nothing of the sort.
Why, oh why can more people not see this...
Linux is a kernel (as opposed to the BSDs which include a set of integrated userland tools - not just package a bunch of independently developed GNU tools), that really, these days is nothing particularly special, other than being "free". I mean sure, certain aspects of it may be cutting edge, but for the most part they're not "must have" features that will make or break it's usage in a particular application.
As much as I think RMS is a idealist nutjob, I can see his point regarding the whole "GNU/Linux" thing here (even though simply tacking "GNU" on the front isn't fair to other developers, without which the system would be useless for certain purposes, such as xfree.org).
A *Freely Licensed* (copy the crap out of it *if* you want, contribute *if* you want, not like GPL), rock solid, incredibly portable, fully functional kernel/OS that will install off of a fraction of a CD.
There's nothing like it,
There's FreeBSD. You can install the base system off an ~120mb install image last I checked. Granted, it's not *quite* as portable, however I would argue that this is not such a major problem these days, with x86 hardware being so cheap and giving good performance. It's "portable enough".
I'm the first to admit that I don't *like* the x86 architecture from an idealistic viewpoint, but it does the job and most of the other architectures are either becoming or actually irrelevant...
It's near on useless with the amount of spam these days anyway. Yes I have severe amounts of filtering. Unfortunately my address(es) were amongst those stolen from various nic registries before the addresses were hidden.
I could still communicate without e-mail, simply give people a web form address to send me stuff:D
As I read this I was reminded of my own experience with DOS 5.0 and my 386/25. Back before the days of the Internet the only resource I had was the DOS 5.0 manual (which actually documented all of the information that I needed to know). My dad used the computer for Lotus123 and WordPerfect, I used it to play games. Every game I wanted to play needed a different bootdisk with a subtly tweaked version of Autoexec.bat and Config.sys to load the right drivers and free up enough of the 640k to play the game right.
Cool story hansel...
Linux today reminds me of DOS fifteen plus years ago. Sure, they have a GUI, but it's a lot like Windows 3.11... just some graphics that are sitting ontop of a command shell that you still do most of your real work in. When something breaks you don't fix it through the GUI, you drop down to the command line and go to work (a la the recent Ubuntu fiasco).
Once you've got Linux installed properly, you *don't* need to ass-about with it. Unlike dos. Linux is not really any different to Windows with respect to the graphical shell sitting on top of a command line environment, except that in Windows ME/NT+ they've removed your access to the underlying shell unless you either boot in recovery mode or fire up a dos box.
I note that you bring up the recent Ubuntu X problem. Shit happens. If that happened (or, for example, you got a bad video driver that borked graphical mode - this has happened to me before) in Windows and you didn't have the recovery console installed, you're fucked. Break out the windows CD and either reinstall over the top or hope the automatic repair works. At least you've *got* the command line option in Ubuntu to fix it as standard.
For kids today, that OS might be Linux and to a certain extent I encourage that, because by using Linux, you're closer to the core of the computer. You're still manually loading drivers and compiling modules and mounting file systems.
Use a distro from the past couple of years and this is not the case. Nvidia drivers in ubuntu are a couple of package manager clicks away. Easier than Windows even (unless you really want to use the outdated drivers on your CD?).
As to your comments about the enterprise services Windows provides, well lets just say that out of Active Directory, group policy, Automatic updates, msi installers, ghost and RDP, there is not one technology listed there that isn't relatively simple to implement in a Linux/BSD environment if you're not a Microsoft admin who refuses to learn.
I've been a regular linux user (incuding system admin for an ISP for 5 years) since 1996.
I have not compiled a Linux kernel since about 2000. Haven't compiled a FreeBSD kernel for some time either. Why? Because the vendor supplied kernel these days is generally good enough, and additional functionality can be added as loadable modules.
To all the "leet" "compile your own kernel!!1" newbie idiots - unless you're prepared to totally give up vendor support, use the stock kernel. It's been compiled on known-good hardware with "known good" configuration options.
If you roll your own, sure, you might think your hardware/kernel options are fine, but to anyone supporting you it's a question-mark straight up.
There's a time and place for compiling kernels, and that's development machines or in a test environment. Not for newbies, and also *not* in a production environment *unless* you're willing to give up your support, or validate that any problems you have occur on the vendor supplied stock kernel as well.
As to the parent poster: give ubtuntu a shot, it will give you a new perspective on what the current state of Linux distributions is. I know I was quite impressed when I tried out 5.10 after not using Linux as a desktop for a couple of years. Sure, Windows only software and Windows only games are a bit of an issue, but it's not really fair to blame that on Linux - these things don't run on Mac OS/X either...
Intel can also afford to go lower at the moment (and keep their profits up) due to their increased wafer size and increased dual core yields by way of "joining" 2 dies together.
Their manufacturing costs have been cut drastically by these two factors.
I'm surprised that there's been no "freedom of speech" B.S. trolled out yet (haven't read the full comments tho).
Whilst I agree that making a blind-accessible site is easy and sensible for any business, I am 100% against the use of regulation and lawsuits to force this.
If a company wants to narrow their audience, and alienate their customer base, fine - let them. They'll lose market share.
This is a classical case of exactly what is wrong with the american legal system in my opinion.
What next, the ability to sue the recording industry for not releasing Braille albumns for the deaf? The ability to sue car dealerships for discrimination if refused a test-drive if you're blind?
Whilst I agree that we're going to have 8 core systems, etc - I don't agree that they're simply going to be sitting idle.
Why waste your general purpose cpu horsepower doing "dumb" and "embarassingly parallel" tasks when it is better used for more complex AI?. Multiple cores are all well and good but my vision is that they'll continue to be used for complex tasks, and the "dumb" (or rather, as you say, embarassingly parallel) rendering processes will continue to be better served by relatively simple, single purpose optimised hardware.
Also, adding cores has not really done heaps in terms of memory bandwidth, which is a large problem with rendering for example. You're better off using a smaller amount of high bandwidth storage (and local custom chips) for tasks like rendering IMHO, than trying to make ALL ram on your system quick enough.
But yeah, i definately agree with the paralellism of graphics algorithms. In fact, it would not surprise me if, in the future, we end up with 1 processor per scanline, or one processor per pixel at some point:)
Interesting point on the art costs, but the way I see it they may actually end up going down...
Currently to get decent looking artwork in games a lot of work goes into making the textures, etc - eventually, i'd wager that much of this can be reduced to procedural synthesis and done by computer (yet more processing power required of course:D).
eg, instead of drawing a metal texture, the 3d artist will simply be able to "tell" the computer that "this surface is made of silver", for example, and the rendering engine will generate the textures/reflections/etc automatically. Using even more processing power, you could build 3d models at the molecular level, and with a sufficiently complex algorithm, render them based on their molecular structure.
I guess more detail (putting scratches and imperfections into the model for example, to simulate wear) will require increased artist input though... then again, that could be simulated as well by supplying the "world generator" with a history of the components that could be simulated...etc:D
Give me cpu power and i'll figure out ways to consume it:D
Sure, you might get 200fps on a current generation game, but if we want to increase the resolution by a factor of 4 (not inconceivable) then you're back down to 50fps. Then say for example you wanted to generate 2 different images for stereo vision, you're down to 25fps... etc. That's not considering new future rendering technologies that are more accurate than the current "good enough" hack type rendering.
Dedicated hardware is more cost effective for a given task than a general purpose processor. Why waste your expensive general purpose CPU on a fairly repetitive single purpose task that can be performed more quickly by a dedicated processor that's half the cost?
I'd agree that within a couple of years you'll get the same level of performance using general purpose CPUs, but by that time there will be even quicker dedicated processors working on the next generation of code that is not feasible to even consider on general purpose hardware of the day. Conversely, the processors that can perform the task that your general purpose processor is finally quick enough to perform will have dropped massively in price.
Slashdot Mirror
It's not IE that's zero day, it's the exploit...
May be worth a shot just asking them, as their equipment quite possibly supports both call types - i'd hazard a guess that it's more an accounting issue than a technical one...
All of my hardware is supported by FreeBSD. USB support worked in the BSDs before it did in linux. The driver "problem" is largely a non-issue. FreeBSD can actually use Windows NDIS drivers for NICs as well...
I was so hoping for the ppc/alpha to take off myself, but alas... "worse is better" strikes again...
It's getting to the point now though that for 99.99% of the coders out there, they couldn't give a crap what a cpu is like to program from an assembly point of view, as most of them wouldn't go any lower level than C these days anyway - most of them won't even go that low...
Definately disagree here.
Linux (or more specifically, "GNU" or "the gnu toolchain") is nothing like 'real' unix when you get further than a cursory observation. The GNU tools are usually different in some subtle way for no *really* good reason (it seems) other than to follow GNU's own "standards".
Examples that spring to mind for example: netstat, ifconfig, info, etc...
If you've used a few flavours of Unix (myself, Solaris, SCO (yes, it sucks), AIX, FreeBSD) the differences (even subtle ones like the display formatting of various commands) in Linux really stand out.
However, calling the operating system "Linux" is not really being truthful either.
There's a lack of a term for describing what it really is ("Linux kernel + free stuff" doesn't have much of a ring to it :D), unless you use a distribution name, i.e., Redhat or Debian, etc.
Yes and no.
I'm aware of the embedded space, but personally I think that within a few years it will all be x86 anyway (much as it's a "crappy" architecture). Also, given that the costs of storage, RAM, etc are dropping extremely quickly, I don't think that worrying about 20mb vs 200-600mb is worth wasting the development time on any more.
But that's my personal opinion...
Why, oh why can more people not see this...
Linux is a kernel (as opposed to the BSDs which include a set of integrated userland tools - not just package a bunch of independently developed GNU tools), that really, these days is nothing particularly special, other than being "free". I mean sure, certain aspects of it may be cutting edge, but for the most part they're not "must have" features that will make or break it's usage in a particular application.
As much as I think RMS is a idealist nutjob, I can see his point regarding the whole "GNU/Linux" thing here (even though simply tacking "GNU" on the front isn't fair to other developers, without which the system would be useless for certain purposes, such as xfree.org).
There's FreeBSD. You can install the base system off an ~120mb install image last I checked. Granted, it's not *quite* as portable, however I would argue that this is not such a major problem these days, with x86 hardware being so cheap and giving good performance. It's "portable enough".
I'm the first to admit that I don't *like* the x86 architecture from an idealistic viewpoint, but it does the job and most of the other architectures are either becoming or actually irrelevant...
Funny, i've got 3D acceleration working just fine in both Linux and FreeBSD on my 7600GT...
You can never *prove* a theory, you can merely disprove it by finding evidence which does not support it.
I could still communicate without e-mail, simply give people a web form address to send me stuff :D
You missed a : between the two statements, either that or a carriage return :D
A) type "apt-get install nvidia-glx" or
b) fire up the package manager and select "nvidia-glx"
Erm, replace "bad video driver" with "bad driver" or "registry corruption"...
Once you've got Linux installed properly, you *don't* need to ass-about with it. Unlike dos. Linux is not really any different to Windows with respect to the graphical shell sitting on top of a command line environment, except that in Windows ME/NT+ they've removed your access to the underlying shell unless you either boot in recovery mode or fire up a dos box.
I note that you bring up the recent Ubuntu X problem. Shit happens. If that happened (or, for example, you got a bad video driver that borked graphical mode - this has happened to me before) in Windows and you didn't have the recovery console installed, you're fucked. Break out the windows CD and either reinstall over the top or hope the automatic repair works. At least you've *got* the command line option in Ubuntu to fix it as standard.
Use a distro from the past couple of years and this is not the case. Nvidia drivers in ubuntu are a couple of package manager clicks away. Easier than Windows even (unless you really want to use the outdated drivers on your CD?).
As to your comments about the enterprise services Windows provides, well lets just say that out of Active Directory, group policy, Automatic updates, msi installers, ghost and RDP, there is not one technology listed there that isn't relatively simple to implement in a Linux/BSD environment if you're not a Microsoft admin who refuses to learn.
I have not compiled a Linux kernel since about 2000. Haven't compiled a FreeBSD kernel for some time either. Why? Because the vendor supplied kernel these days is generally good enough, and additional functionality can be added as loadable modules.
To all the "leet" "compile your own kernel!!1" newbie idiots - unless you're prepared to totally give up vendor support, use the stock kernel. It's been compiled on known-good hardware with "known good" configuration options.
If you roll your own, sure, you might think your hardware/kernel options are fine, but to anyone supporting you it's a question-mark straight up.
There's a time and place for compiling kernels, and that's development machines or in a test environment. Not for newbies, and also *not* in a production environment *unless* you're willing to give up your support, or validate that any problems you have occur on the vendor supplied stock kernel as well.
As to the parent poster: give ubtuntu a shot, it will give you a new perspective on what the current state of Linux distributions is. I know I was quite impressed when I tried out 5.10 after not using Linux as a desktop for a couple of years. Sure, Windows only software and Windows only games are a bit of an issue, but it's not really fair to blame that on Linux - these things don't run on Mac OS/X either...
Impurities (coffee, milk, sugar) raise water's boiling point.
Their manufacturing costs have been cut drastically by these two factors.
Whilst I agree that making a blind-accessible site is easy and sensible for any business, I am 100% against the use of regulation and lawsuits to force this.
If a company wants to narrow their audience, and alienate their customer base, fine - let them. They'll lose market share.
This is a classical case of exactly what is wrong with the american legal system in my opinion.
What next, the ability to sue the recording industry for not releasing Braille albumns for the deaf? The ability to sue car dealerships for discrimination if refused a test-drive if you're blind?
Why waste your general purpose cpu horsepower doing "dumb" and "embarassingly parallel" tasks when it is better used for more complex AI?. Multiple cores are all well and good but my vision is that they'll continue to be used for complex tasks, and the "dumb" (or rather, as you say, embarassingly parallel) rendering processes will continue to be better served by relatively simple, single purpose optimised hardware.
Also, adding cores has not really done heaps in terms of memory bandwidth, which is a large problem with rendering for example. You're better off using a smaller amount of high bandwidth storage (and local custom chips) for tasks like rendering IMHO, than trying to make ALL ram on your system quick enough.
But yeah, i definately agree with the paralellism of graphics algorithms. In fact, it would not surprise me if, in the future, we end up with 1 processor per scanline, or one processor per pixel at some point :)
Currently to get decent looking artwork in games a lot of work goes into making the textures, etc - eventually, i'd wager that much of this can be reduced to procedural synthesis and done by computer (yet more processing power required of course :D).
eg, instead of drawing a metal texture, the 3d artist will simply be able to "tell" the computer that "this surface is made of silver", for example, and the rendering engine will generate the textures/reflections/etc automatically. Using even more processing power, you could build 3d models at the molecular level, and with a sufficiently complex algorithm, render them based on their molecular structure.
I guess more detail (putting scratches and imperfections into the model for example, to simulate wear) will require increased artist input though... then again, that could be simulated as well by supplying the "world generator" with a history of the components that could be simulated...etc :D
Give me cpu power and i'll figure out ways to consume it :D
Sure, you might get 200fps on a current generation game, but if we want to increase the resolution by a factor of 4 (not inconceivable) then you're back down to 50fps. Then say for example you wanted to generate 2 different images for stereo vision, you're down to 25fps... etc. That's not considering new future rendering technologies that are more accurate than the current "good enough" hack type rendering.
Dedicated hardware is more cost effective for a given task than a general purpose processor. Why waste your expensive general purpose CPU on a fairly repetitive single purpose task that can be performed more quickly by a dedicated processor that's half the cost?
I'd agree that within a couple of years you'll get the same level of performance using general purpose CPUs, but by that time there will be even quicker dedicated processors working on the next generation of code that is not feasible to even consider on general purpose hardware of the day. Conversely, the processors that can perform the task that your general purpose processor is finally quick enough to perform will have dropped massively in price.
That's what history tells me, anyway... :)
Aha... so in other words, this NIC is a potential security hole that can not easily be closed :)