Re:Linux really does have serious issues
on
Linux Sucks (Video)
·
· Score: 2
It isn't just a lack of applications - many of those that are included in a typical desktop distro are either unstable or lacking features. I put it down to a few things:
Hobbyist developer(s) who have an itch to scratch, get the app to do what they want and then lose interest when it gets hard (not all cases - there are many talented developers out there who persist, but they don't tend to be desktop application developers
Constantly changing API(s) mean so much time is wasted re-inventing the wheel porting to the current desktop environment flavor of the month
Hardware support is an issue that will fix itself when people have an incentive to run the platform to get actual work done (and by work, I don't just mean network administration and other nerd stuff. i mean actual work that one would do in an office during the course of a typical business).
Make Linux business friendly, with business/corporate friendly apps and the bean-counters will sit up and take notice. I doubt that will happen any time soon though due to the inherent disconnect between the open source development attitude and corporate needs.
Those problems were mostly fixed in Windows NT5, assuming you followed basic security hygiene as you would with Linux and disabled services, didn't run everything logged in as administrator, etc.
Re:Basic misunderstandings and self-contradictions
on
Linux Sucks (Video)
·
· Score: 1
Um... X11 was long in the tooth in 1996, with the release of NT 4 Terminal server. Which did usable remote display using RDP in a fraction of the bandwidth. Many other parts of NT4 sucked, but RDP is actually pretty high performance, especially since Windows 2000.
Ran Linux extensively between 1995 and 2006. I still have Linux servers, but they're mostly FreeBSD now.
It (and the free desktop in general) sucks, and many of the broken things that I wished were fixed in say, 2000 are either still broken or (in the case of actual software stability) even worse now. Example: playing media from a network share. What the FUCK is my desktop environment attempting to copy the fucking file off the network into temporary storage before playing it doing that for? OS X? Plays from network share. Windows? Plays from network share. Linux? Oh, let me copy that 1 GB video file for you over WIFI before I will play it. I'll be ready in few minutes.
Yes, i could mount the share under a folder manually using the shell and pretend it is local. Why the fuck should I have to? It is un-necessary grunt work that the computer can and should do for me when i browse the network using a file manager.
Don't even get me started on the myriad of different file open dialogs, (some which are network aware, some which aren't) on a typical desktop install. Never mind the inconsistency of keyboard shortcuts, desktop stability (you know the last time I had the OS X GUI lock up on me? Hint, it's not this year or last year. In KDE? within 15 minutes of playing with it to check up on whether any progress in the above areas have been made this year. I remember using (and compiling from source) KDE 1.0, 2.0 and 3.x and they were way more stable than the current KDE releases.
Linux and the free unix desktop has so much potential, but the pervasive refusal to use existing libraries, standardize on anything or actually fucking finish any single component of the OS before trashing it and replacing it with something else means that it is constantly a case of two steps forward, two steps back, with the occasional actual advance, generally due to ripping off the UI of either Windows (in the 90s) or OS X (currently), without making the underlying infrastructure work properly to support the functions those respective desktops actually provide.
Look... the GUI is a solved problem for the most part. Many people are happy to stay on Windows XP, which was released 12 years ago and was only a minor GUI update from Windows 95. Stop re-inventing the wheel, trashing everything and starting over, and actually get the unix desktop stable, and implement the functionality. I couldn't give a fuck if i have transparent windows or rotating cube desktop switching or whatever. I just want the applications I use to actually WORK, please.
Rant over. No doubt a bunch of fanboys will moderate this flamebait, troll, or whatever, but I don't care. Covering ears and refusing to admit to any of the free desktop usability flaws (note: not UX - i'm talking software stability and feature set) will just ensure that the Free unix desktop continues to fail.
No, this isn't actually irrelevant. It is the primary reason I abandoned non-intel systems actually. Not specifically blown caps, but simply because there are so many shitty motherboard chipsets out there for alternative CPUs.
CPU isn't so much what drives my machine purchases since about 1996 - it's motherboard chipset: driver support, bugs, compatibility, etc.
Not to say that intel chipsets never have bugs, but it is more likely that the software I run has put in sufficient work-arounds and testing is done that I end up with a stable system. Yes, this in anecdotal, but since I've gone exclusively intel for my motherboard chipsets in 1997, i can count the number of non-RAM related blue screens I have had on one hand (and these were Nvidia GPU driver related).
So what if I'm encoding from a batch? If its going to take 24 hours on the K6 or 12 (or 18, or 22 - whatever) hours on the Pentium 3, it still means I'm waiting longer to be able to do anything with the end result.
The athlon was a hit because AMD had bought a huge amount of technology and know-how from Alpha personnel. There is no DEC Alpha to borrow technology from this time around.
I think you over-estimate the clutter required to support old 1970s instructions in an x64 chip. They have billions of transistors and an instruction decoder. The entire 486 CPU (the last CPU with the instructions not decoupled from the internal design) was implemented in 1 million transistors or so. Less than 0.1 percent of a typical modern x64 CPU if it was implemented in hardware, and it is most likely NOT implemented in hardware, but microcode...
Nah, it's more like using engine capacity as a measure of speed... horsepower, when combined with weight can be a rough indication. Engine capacity, not so much. It very much depends on the efficiency of the engine.
Yup. What many people forget is that netburst was intended to scale way, way beyond the clock-rate it was released at. Intel fully expected us to be running 10Ghz on silicon (and beyond) by 2004, so they optimized the Netburst architecture to run at that rate. It wasn't low IPC because it was a bad design, it was designed to be low IPC to enable it to scale to ridiculous clock-speed that was expected to be possible (because at the time, the P6 based Pentium 3 had pretty much hit a wall around 1-1.3 Ghz).
The current situation, where we have stagnated around 3Ghz or so for the past decade was unexpected, and not predicted to be a scaling barrier as manufacturing process shrunk.
Netburst may actually end up making a comeback if we move to a different CPU technology to silicon, and are able to ramp up clock-speeds to the level where it makes sense.
The newer atom style CPUs, and even recent core i series have massively dropped x86/x64 power consumption. I suspect ARM in the server room is a flash in the pan, and intel is going to prevail in that space simply due to the huge legacy of x86 code. ARM will face the same problem as Itanium in that respect - performance emulating x86 code will suck.
Sure, for basic web services on open source software ARM may be fine, but with cloud services being the current big thing, and companies wanting to migrate their x86 based applications to the cloud, ARM just isn't going to cut it. Atom is similar in power consumption to ARM now and provides a relatively seamless transition to/from full-fat x64 Core series or Xeon as performance requirements dictate. ARM simply can't scale to that degree at the moment.
Nah, the original guy posting about his Macbook pro is correct. I also have a 2011 macbook pro with Sandy bridge, an i7-2720 quad core, 2.2Ghz. GPU performance is different, power consumption is better now, but in terms of raw performance on CPU, it's a wash. The 1990s style gains of 2x performance every 18 months or so are well and truly gone.
But yes, i agree, desktop CPU performance has pretty much stalled since the Sandy Bridge machines. I suspect it is because AMD simply dropped the ball and intel hasn't seen any need to push the envelope yet.
The question is why would you bother? A modern x64 CPU has billions of transistors. The 486 CPU (which has 16/32 bit compatibility) was implemented entirely in around 1 million transistors. You're going to save a fraction of a percent of the CPU die, whilst breaking virtually all software written prior to 1992, and probably a lot of niche software written after that. It's not worth it.
Um.... Itanium failed for 2 reasons. The second one being price. It wasn't just Xeon priced, it was way more expensive than that. It wasn't just outperformed by an equivalent priced Xeon (that didn't exist, they were cheaper), it was destroyed performance wise by consumer non-xeon CPUs on x86 code.
Which happens to be all of the code people actually cared about running.
The p4 had hyper-threading added in an attempt to save the botched design that caused unused CPU resources due to pipeline stalls.
Intel are coasting at the moment. Why release something faster than the already fastest consumer CPUs available on the market they are already making when AMD are so busy shooting themselves in the foot? Let AMD spend billions on a new architecture, then release the faster CPU that intel no doubt already have waiting, to compete with that.
Slashdot Mirror
It isn't just a lack of applications - many of those that are included in a typical desktop distro are either unstable or lacking features. I put it down to a few things:
Hardware support is an issue that will fix itself when people have an incentive to run the platform to get actual work done (and by work, I don't just mean network administration and other nerd stuff. i mean actual work that one would do in an office during the course of a typical business).
Make Linux business friendly, with business/corporate friendly apps and the bean-counters will sit up and take notice. I doubt that will happen any time soon though due to the inherent disconnect between the open source development attitude and corporate needs.
"Because he talked shit something i like"
Those problems were mostly fixed in Windows NT5, assuming you followed basic security hygiene as you would with Linux and disabled services, didn't run everything logged in as administrator, etc.
Um... X11 was long in the tooth in 1996, with the release of NT 4 Terminal server. Which did usable remote display using RDP in a fraction of the bandwidth. Many other parts of NT4 sucked, but RDP is actually pretty high performance, especially since Windows 2000.
Ran Linux extensively between 1995 and 2006. I still have Linux servers, but they're mostly FreeBSD now.
It (and the free desktop in general) sucks, and many of the broken things that I wished were fixed in say, 2000 are either still broken or (in the case of actual software stability) even worse now. Example: playing media from a network share. What the FUCK is my desktop environment attempting to copy the fucking file off the network into temporary storage before playing it doing that for? OS X? Plays from network share. Windows? Plays from network share. Linux? Oh, let me copy that 1 GB video file for you over WIFI before I will play it. I'll be ready in few minutes.
Yes, i could mount the share under a folder manually using the shell and pretend it is local. Why the fuck should I have to? It is un-necessary grunt work that the computer can and should do for me when i browse the network using a file manager.
Don't even get me started on the myriad of different file open dialogs, (some which are network aware, some which aren't) on a typical desktop install. Never mind the inconsistency of keyboard shortcuts, desktop stability (you know the last time I had the OS X GUI lock up on me? Hint, it's not this year or last year. In KDE? within 15 minutes of playing with it to check up on whether any progress in the above areas have been made this year. I remember using (and compiling from source) KDE 1.0, 2.0 and 3.x and they were way more stable than the current KDE releases.
Linux and the free unix desktop has so much potential, but the pervasive refusal to use existing libraries, standardize on anything or actually fucking finish any single component of the OS before trashing it and replacing it with something else means that it is constantly a case of two steps forward, two steps back, with the occasional actual advance, generally due to ripping off the UI of either Windows (in the 90s) or OS X (currently), without making the underlying infrastructure work properly to support the functions those respective desktops actually provide.
Look... the GUI is a solved problem for the most part. Many people are happy to stay on Windows XP, which was released 12 years ago and was only a minor GUI update from Windows 95. Stop re-inventing the wheel, trashing everything and starting over, and actually get the unix desktop stable, and implement the functionality. I couldn't give a fuck if i have transparent windows or rotating cube desktop switching or whatever. I just want the applications I use to actually WORK, please.
Rant over. No doubt a bunch of fanboys will moderate this flamebait, troll, or whatever, but I don't care. Covering ears and refusing to admit to any of the free desktop usability flaws (note: not UX - i'm talking software stability and feature set) will just ensure that the Free unix desktop continues to fail.
ps. my power rate here in Australia is roughly 26c (aussie) per kw/h, and my machine is turned on approximately 12+ hours per day.
Please find me a competitive AMD CPU that wins against my core i5-4430 over 3 years with power consumption taken into account. Cheers.
No, this isn't actually irrelevant. It is the primary reason I abandoned non-intel systems actually. Not specifically blown caps, but simply because there are so many shitty motherboard chipsets out there for alternative CPUs.
CPU isn't so much what drives my machine purchases since about 1996 - it's motherboard chipset: driver support, bugs, compatibility, etc.
Not to say that intel chipsets never have bugs, but it is more likely that the software I run has put in sufficient work-arounds and testing is done that I end up with a stable system. Yes, this in anecdotal, but since I've gone exclusively intel for my motherboard chipsets in 1997, i can count the number of non-RAM related blue screens I have had on one hand (and these were Nvidia GPU driver related).
Newsflash: lack of competitor sees intel hold off on new technology release!
So what if I'm encoding from a batch? If its going to take 24 hours on the K6 or 12 (or 18, or 22 - whatever) hours on the Pentium 3, it still means I'm waiting longer to be able to do anything with the end result.
The athlon was a hit because AMD had bought a huge amount of technology and know-how from Alpha personnel. There is no DEC Alpha to borrow technology from this time around.
And it was still inferior to the Pentium II, because AMD (literally) couldn't make an 8087 compatible GPU to save their life until the Athlon series.
I think you over-estimate the clutter required to support old 1970s instructions in an x64 chip. They have billions of transistors and an instruction decoder. The entire 486 CPU (the last CPU with the instructions not decoupled from the internal design) was implemented in 1 million transistors or so. Less than 0.1 percent of a typical modern x64 CPU if it was implemented in hardware, and it is most likely NOT implemented in hardware, but microcode...
Nah, it's more like using engine capacity as a measure of speed... horsepower, when combined with weight can be a rough indication. Engine capacity, not so much. It very much depends on the efficiency of the engine.
No, 50% improvement is nowhere near what we "want". Order of magnitude improvements are what people really want/need.
Try encoding high def video.
They didn't "forget" this, because the extent to which this was a problem beyond 3Ghz was not yet known when Netburst was under development.
Yup. What many people forget is that netburst was intended to scale way, way beyond the clock-rate it was released at. Intel fully expected us to be running 10Ghz on silicon (and beyond) by 2004, so they optimized the Netburst architecture to run at that rate. It wasn't low IPC because it was a bad design, it was designed to be low IPC to enable it to scale to ridiculous clock-speed that was expected to be possible (because at the time, the P6 based Pentium 3 had pretty much hit a wall around 1-1.3 Ghz).
The current situation, where we have stagnated around 3Ghz or so for the past decade was unexpected, and not predicted to be a scaling barrier as manufacturing process shrunk.
Netburst may actually end up making a comeback if we move to a different CPU technology to silicon, and are able to ramp up clock-speeds to the level where it makes sense.
Agreed. And it hasn't really been true since the 386 introduced protected mode.
The newer atom style CPUs, and even recent core i series have massively dropped x86/x64 power consumption. I suspect ARM in the server room is a flash in the pan, and intel is going to prevail in that space simply due to the huge legacy of x86 code. ARM will face the same problem as Itanium in that respect - performance emulating x86 code will suck.
Sure, for basic web services on open source software ARM may be fine, but with cloud services being the current big thing, and companies wanting to migrate their x86 based applications to the cloud, ARM just isn't going to cut it. Atom is similar in power consumption to ARM now and provides a relatively seamless transition to/from full-fat x64 Core series or Xeon as performance requirements dictate. ARM simply can't scale to that degree at the moment.
Nah, the original guy posting about his Macbook pro is correct. I also have a 2011 macbook pro with Sandy bridge, an i7-2720 quad core, 2.2Ghz. GPU performance is different, power consumption is better now, but in terms of raw performance on CPU, it's a wash. The 1990s style gains of 2x performance every 18 months or so are well and truly gone.
But yes, i agree, desktop CPU performance has pretty much stalled since the Sandy Bridge machines. I suspect it is because AMD simply dropped the ball and intel hasn't seen any need to push the envelope yet.
The question is why would you bother? A modern x64 CPU has billions of transistors. The 486 CPU (which has 16/32 bit compatibility) was implemented entirely in around 1 million transistors. You're going to save a fraction of a percent of the CPU die, whilst breaking virtually all software written prior to 1992, and probably a lot of niche software written after that. It's not worth it.
Um.... Itanium failed for 2 reasons. The second one being price. It wasn't just Xeon priced, it was way more expensive than that. It wasn't just outperformed by an equivalent priced Xeon (that didn't exist, they were cheaper), it was destroyed performance wise by consumer non-xeon CPUs on x86 code.
Which happens to be all of the code people actually cared about running.
Intel do not massively over-charge for their product. If they did, people would buy AMD instead.
The p4 had hyper-threading added in an attempt to save the botched design that caused unused CPU resources due to pipeline stalls.
Intel are coasting at the moment. Why release something faster than the already fastest consumer CPUs available on the market they are already making when AMD are so busy shooting themselves in the foot? Let AMD spend billions on a new architecture, then release the faster CPU that intel no doubt already have waiting, to compete with that.