This isn't change for the sake of change. It is change for the sake of ubiquitous computing. They have to get rid of a ton of assumptions that go into Windows 95-Windows 7 GUI design.
Assumptions about a narrow range of dpi that allow bitmaps to function Assumptions about a narrow range of input devices Assumptions that applications don't have to adapt to different output sizes etc...
I think in general Windows 7 is a major improvement on greenbar terminals. On the other hand, I can't read my old outputs and inputs. I've had to lose some things. Windows 8 is revolutionary change similar to the move from DOS to Windows. Vista / Windows 7 was evolutionary change from XP.
XP 64 was (desktop not server) never really panned out. I'm glad to hear stuff is breaking. I haven't seen much of that but if so, then good. Let's get some apps using Windows 7 features.
But even so, the basic interface in Windows 7 is still the same. Because it works. New hardware capabilities, etc. are not an excuse to throw away well-established, and well-justified, human interface principles.
Of course they are. New hardware capabilities are what should drive new interfaces. Hard drives allowed us to move away from reel-to-reel tape as output. The ability to connect lots of terminals allowed us to move to interactional systems and get rid of setting up batches of punchcards to write tape for input. The ability to send data to screens fast allowed us to put the curser in random positions allowed curses style interfaces. The ability to draw graphics smaller than readable text allow for early GUIs. Faster CPUs and distributed allowed for event driven GUIs, etc...
That's not a problem. Microsoft does't have a problem in the enterprise space, Enterprise customers have been buying better hardware and more importantly expensive server products from Microsoft. They aren't planning on leaving the Windows ecosystem and are locked on. They aren't the core problem. For enterprise customers the focus is getting them all off XP and getting the next round of business applications to use Windows 7 only features.
XP released Oct 2001 End of Support April 2014 (12.5 yrs) Win7 released July 2009 End of extended Support Jan 2020 (10.5 yrs)
Around January 12, 2015 when regular support ends you'll start seeing some migration towards, probably Windows 9.
I was talking about your example of your 70 something mom. That's consumer / small business and they are a problem
Your 70 something your old mom probably buys cheap computers with no margin. Which means Microsoft's OEMs aren't making money. It also means that Microsoft's OSes can't include hardware intensive features. And those two things mean that Microsoft application ecosystem is still Windows XP compatible... And all that together means that Microsoft is falling far behind in terms of consumer / small business.
What they are thinking is they need to break that cycle. And they are OK with their conservative and cheap userbase being unhappy about it.
* Poor parallelism. I suspect that there's no ETL tool out there that can parse a CSV file in parallel. It's hard, because all but the first thread has to "hold" its results and potentially back-track. There are organizations out there that import multi-gigabyte text files!
I think you can do a bit better than that. This is just off the top of my head but...
Let CSV parse be a function that takes a blog consisting of parts of a CSV file and a record structure. It returns a list of guess for where the next record starts. Elements of the list look like:: (guess position, extra front bytes, extra rear bytes, parsed intermediate CSV)
This has a natural addition operation, which you'll notice is associative. (GP1, EF1, ER1, PC1) + (GP2, EF2, ER2, PC2) = (GP1, EF1, ER2, PC1 + parse (ER1 + EF2) + PC2)
The sume of two lists is just the sum of all possibilities: [A1, A2, A3 ] + [B1, B2] = [A1+B1, A1 + B2, A2+B1.., A3+B2]
Then you just pass till you find a good guess at each stage. The algorithm has to be lazy so a parser can generate this list fast, it doesn't have to do much parsing other than finding plausible guess position. The reducer just throws out bad guesses. When it finds a good guess (i.e. the right spot) it goes ahead and evaluates the interior structures.
This paralyzes easily, though you'll spend a huge amount of time working on computations on bad guess. But if you have enough CPUs relative to record size (say 1000 CPUs ) you would get done a lot faster.
1) Finds files 2) Auto searches for metadata 3) Files the duplicates once keydata is entered by group -> album 4) Allows you to sort the list by about 40 criteria
I'm sure most of the other music players do the same thing.
I think the obvious thing would be an associative database filesystem for the/home directory.
Essentially this would be a filesystem that responds to requests to open... a file by copying it off to something like/var/tmp/home and allowing normal sequential access. On file close the file gets fully indexed and put in the associative database. The directory location should be tagged and end users should be able to tie keywords to files using an associative scheme.
So for example/home/steve/homework/Math232/2011-Mar-14.odt comes up in a query for all Math homework since the database contains an association between Math and Math232 and 2011-Mar-14.odt is associated with Math232 automatically. Further if problem 7 is about a cubic equations this file should pop up in an association of "cubics" because of the association cubics -> cubic equation -> 2011-Mar-14.odt
An associative database can be implemented using a relational in the normal ways.
That dropping of support has nothing to do with graphics. Microsoft's languages division has always been very iffy in Mac support. Microsoft pruned Foxpro immediately dropping the Unix and DOS ports and then the Mac parts. That might have been around 1996 but the product still existed for several more years. If you meant graphical elements support your version of history isn't what happened.
As for storage and retrieval of graphical elements, that was a GUI function. Microsoft enhanced this capability in Visual FoxPro 9, they didn't kill it. But ultimately Microsoft larger corporate direction was away from XBase type applications and towards fully relational databases whose application layer used MVC. You don't need a different database you just pulled graphics as presentation layer from the database.
Just as an aside, your notions of mortality rates are really high. I doubt you would see numbers like that for dogs. For example in the USA the total for everything combined is slightly higher than 8 per 1000. South Africa is the highest in the world at slightly over double that. Heart disease and cancers are about 1/4 each so you would 2 for heart and 2 for cancer. Food I'm seeing numbers all over the place but around 0.16 / thousand for serious illness. I can't even find numbers for humans that result in death they are so small. Mind you, I can find numbers for people breathing in food and dying from it, 0.058.
Of course the entire premise is wrong. There has been a huge increase in European food contamination over the last 2 decades and it has been noticed. Rates there are much higher than here. Though the big issue there is contamination of the food itself due to not wanting to use genetically resistant feed.
Huh? Visual FoxPro was killed well into the windows era, mid 2000s. Huge chunks of the code wouldn't work with 64 bit systems they had no reasonable porting strategy. They would have had to do a rewrite and they saw no point in a rewrite. The strategy they had been pushing for years was using SQLServer for the backend and using industry standard communication protocols for the client often written in Visual Basic. This had nothing to do with graphics but rather Microsoft's embrace of 2-tier (and later n-tier) architecture.
NeXTStep was and so were the SGIs which were even cooler on graphics and video. The Suns weren't half bad either. The workstation class computers of the late 80's and early 90's had the hardware that would go into desktops much later. Arguably Apple's focus for developing the video, audio, animation capacity was creating cheaper more mainstream versions of SGI technology. And just as you can compare today's high end smartphones to late 90's early 2000s computers, but not 2013 computers you can compare workstations 1988-1994 to computers
1990 style NeXT would be something on the computer order of:
Pentium 1 - 75 mhz with good quality video and sound card 32 mb ram dual SCSI drive, 2 g.
That would have been an expensive x86 computer even in 1994. Lets call it a general purpose desktop around 1997 when the MMX pentiums came out.
Great argument. I agree with you. In general video distorted the whole Flash/Shockwave paradigm which could have been an excellent tool for interactivity. It would be nice if someone would stop in and rebuild these.
Well actually X-Client, The X-Server is what would be running remotely.
But besides that nitpick, the big issue is that an X-Client runs the applications which doesn't allow for the high ratio. Part of the web standard is to distribute the processing off to clients (normal meaning of the term) as much as possible.
Back in the early 1990s, complex vector graphics frequently didn't resolve to screen graphics in real time. You may be forgetting how much slower CPUs were.
3D interfaces make use of your notion of distance to allow you to see much larger groups of things and understand where they are. Your brain has huge subsystems designed for overview scans, if there is any sort of sane order you'll be able to understand thousands of controls if they are presented to you in a 3D interface. That allows for very complex software.
For example go to the bottom of http://www.huffingtonpost.com/ and click on the links: politics, style... and see how you have no idea where anything is. Do that with a 3D interface and they could present tens of thousands of stories to you in a way that you would in some vague sense be aware of them.
GCC is C. This is a job for a scripting language not a low level compiled language. Typically GNU uses Scheme as their scripting language. But knowledge of Scheme and Scheme syntax is decreasing. Perl has good support for parsing, tons of people know it, It seems like a reasonable choice for GNU to start doing scripting type stuff in. The Perl community has been active with free software for a long time and hasn't gotten involved in anything questionable.
Nope that predates me that goes back to the days of analog computers. Processing units were parts of a computer where calculations took place. Other parts of the computer might be systems that for example wrote tape to greenbar or the parts that handled input from remote terminal units.
A central processing unit comes from the digital age. It was the unit that contained all the transistor boards that made up the processing unit. Additional processing units might exist in other system but the central one was expensive.
Once you had microprocessing most systems had a single chip responsible for program execution and that took on the name "CPU". Other people continued to refer to the entire box containing the processing transistors as the CPU.
No partially is the best they decided to do. Project was killed.
As for believing that 0 overhead is the best, that's an argument against GUIs, against hardware abstraction, against OO programming, against dynamic languages... You want maximum hardware efficiency use punchcards or dip switches no OS and program hardware directly in assembly.
I think this is a slightly different argument. Clearly there are some cost savings from the scale of the PC industry. A drop off of 20, 50, 90, 95% is unlikely to have a huge impact on prices because where I think the compensation will come from is in the area of diversity. I.E. there will just be far fewer hardware available. For example when Intel made the 8088 it came in one speed 5mhz. Later they brought out an 8mhz version and you could get it in two speeds.
The 386 came out in: 16, 20, 25, 33 mhz (later called the 386DX) 4 models. When the chip became far and away the most successful chip ever there were more variants.
We likely return to a situation more like that 95-99.9% drop off. The real issue is whether the rich phone / tablet market then makes PC architecture cost inefficient for the same performance like what happened to SGI, DEC and later Sun. And I don't think so. I think the server market is doing so well that this is unlikely to happen for a very long time.
Slashdot Mirror
This isn't change for the sake of change. It is change for the sake of ubiquitous computing. They have to get rid of a ton of assumptions that go into Windows 95-Windows 7 GUI design.
Assumptions about a narrow range of dpi that allow bitmaps to function
Assumptions about a narrow range of input devices
Assumptions that applications don't have to adapt to different output sizes
etc...
I think in general Windows 7 is a major improvement on greenbar terminals. On the other hand, I can't read my old outputs and inputs. I've had to lose some things. Windows 8 is revolutionary change similar to the move from DOS to Windows. Vista / Windows 7 was evolutionary change from XP.
XP 64 was (desktop not server) never really panned out. I'm glad to hear stuff is breaking. I haven't seen much of that but if so, then good. Let's get some apps using Windows 7 features.
But even so, the basic interface in Windows 7 is still the same. Because it works. New hardware capabilities, etc. are not an excuse to throw away well-established, and well-justified, human interface principles.
Of course they are. New hardware capabilities are what should drive new interfaces. Hard drives allowed us to move away from reel-to-reel tape as output. The ability to connect lots of terminals allowed us to move to interactional systems and get rid of setting up batches of punchcards to write tape for input. The ability to send data to screens fast allowed us to put the curser in random positions allowed curses style interfaces. The ability to draw graphics smaller than readable text allow for early GUIs. Faster CPUs and distributed allowed for event driven GUIs, etc...
I couldn't disagree more.
That's not a problem. Microsoft does't have a problem in the enterprise space, Enterprise customers have been buying better hardware and more importantly expensive server products from Microsoft. They aren't planning on leaving the Windows ecosystem and are locked on. They aren't the core problem. For enterprise customers the focus is getting them all off XP and getting the next round of business applications to use Windows 7 only features.
XP released Oct 2001 End of Support April 2014 (12.5 yrs)
Win7 released July 2009 End of extended Support Jan 2020 (10.5 yrs)
Around January 12, 2015 when regular support ends you'll start seeing some migration towards, probably Windows 9.
I was talking about your example of your 70 something mom. That's consumer / small business and they are a problem
Your 70 something your old mom probably buys cheap computers with no margin. Which means Microsoft's OEMs aren't making money. It also means that Microsoft's OSes can't include hardware intensive features. And those two things mean that Microsoft application ecosystem is still Windows XP compatible ... And all that together means that Microsoft is falling far behind in terms of consumer / small business.
What they are thinking is they need to break that cycle. And they are OK with their conservative and cheap userbase being unhappy about it.
Narrower scrollbars are harder to use
Scrollbars in Mountain Lion expand when you move to them. So they agree.
As for the drop off in color. I agree Apple is going very bland and very sedate. OTOH they have been getting an older user base.
That's not a troll, if you do that knowingly that's criminal fraud.
* Poor parallelism. I suspect that there's no ETL tool out there that can parse a CSV file in parallel. It's hard, because all but the first thread has to "hold" its results and potentially back-track. There are organizations out there that import multi-gigabyte text files!
I think you can do a bit better than that. This is just off the top of my head but...
Let CSV parse be a function that takes a blog consisting of parts of a CSV file and a record structure.
It returns a list of guess for where the next record starts. Elements of the list look like:: (guess position, extra front bytes, extra rear bytes, parsed intermediate CSV)
This has a natural addition operation, which you'll notice is associative.
(GP1, EF1, ER1, PC1) + (GP2, EF2, ER2, PC2) = (GP1, EF1, ER2, PC1 + parse (ER1 + EF2) + PC2)
The sume of two lists is just the sum of all possibilities: [A1, A2, A3 ] + [B1, B2] = [A1+B1, A1 + B2, A2+B1.., A3+B2]
Then you just pass till you find a good guess at each stage. The algorithm has to be lazy so a parser can generate this list fast, it doesn't have to do much parsing other than finding plausible guess position. The reducer just throws out bad guesses. When it finds a good guess (i.e. the right spot) it goes ahead and evaluates the interior structures.
This paralyzes easily, though you'll spend a huge amount of time working on computations on bad guess. But if you have enough CPUs relative to record size (say 1000 CPUs ) you would get done a lot faster.
1) Finds files
2) Auto searches for metadata
3) Files the duplicates once keydata is entered by group -> album
4) Allows you to sort the list by about 40 criteria
I'm sure most of the other music players do the same thing.
I think the obvious thing would be an associative database filesystem for the /home directory.
Essentially this would be a filesystem that responds to requests to open... a file by copying it off to something like /var/tmp/home and allowing normal sequential access. On file close the file gets fully indexed and put in the associative database. The directory location should be tagged and end users should be able to tie keywords to files using an associative scheme.
So for example /home/steve/homework/Math232/2011-Mar-14.odt
comes up in a query for all Math homework since the database contains an association between Math and Math232 and 2011-Mar-14.odt is associated with Math232 automatically. Further if problem 7 is about a cubic equations this file should pop up in an association of "cubics" because of the association cubics -> cubic equation -> 2011-Mar-14.odt
An associative database can be implemented using a relational in the normal ways.
That dropping of support has nothing to do with graphics. Microsoft's languages division has always been very iffy in Mac support. Microsoft pruned Foxpro immediately dropping the Unix and DOS ports and then the Mac parts. That might have been around 1996 but the product still existed for several more years. If you meant graphical elements support your version of history isn't what happened.
As for storage and retrieval of graphical elements, that was a GUI function. Microsoft enhanced this capability in Visual FoxPro 9, they didn't kill it. But ultimately Microsoft larger corporate direction was away from XBase type applications and towards fully relational databases whose application layer used MVC. You don't need a different database you just pulled graphics as presentation layer from the database.
Just as an aside, your notions of mortality rates are really high. I doubt you would see numbers like that for dogs. For example in the USA the total for everything combined is slightly higher than 8 per 1000. South Africa is the highest in the world at slightly over double that. Heart disease and cancers are about 1/4 each so you would 2 for heart and 2 for cancer. Food I'm seeing numbers all over the place but around 0.16 / thousand for serious illness. I can't even find numbers for humans that result in death they are so small. Mind you, I can find numbers for people breathing in food and dying from it, 0.058.
Of course the entire premise is wrong. There has been a huge increase in European food contamination over the last 2 decades and it has been noticed. Rates there are much higher than here. Though the big issue there is contamination of the food itself due to not wanting to use genetically resistant feed.
Huh? Visual FoxPro was killed well into the windows era, mid 2000s. Huge chunks of the code wouldn't work with 64 bit systems they had no reasonable porting strategy. They would have had to do a rewrite and they saw no point in a rewrite. The strategy they had been pushing for years was using SQLServer for the backend and using industry standard communication protocols for the client often written in Visual Basic. This had nothing to do with graphics but rather Microsoft's embrace of 2-tier (and later n-tier) architecture.
NeXTStep was and so were the SGIs which were even cooler on graphics and video. The Suns weren't half bad either. The workstation class computers of the late 80's and early 90's had the hardware that would go into desktops much later. Arguably Apple's focus for developing the video, audio, animation capacity was creating cheaper more mainstream versions of SGI technology. And just as you can compare today's high end smartphones to late 90's early 2000s computers, but not 2013 computers you can compare workstations 1988-1994 to computers
1990 style NeXT would be something on the computer order of:
Pentium 1 - 75 mhz
with good quality video and sound card
32 mb ram
dual SCSI drive, 2 g.
That would have been an expensive x86 computer even in 1994. Lets call it a general purpose desktop around 1997 when the MMX pentiums came out.
Great argument. I agree with you. In general video distorted the whole Flash/Shockwave paradigm which could have been an excellent tool for interactivity. It would be nice if someone would stop in and rebuild these.
Well actually X-Client, The X-Server is what would be running remotely.
But besides that nitpick, the big issue is that an X-Client runs the applications which doesn't allow for the high ratio. Part of the web standard is to distribute the processing off to clients (normal meaning of the term) as much as possible.
Back in the early 1990s, complex vector graphics frequently didn't resolve to screen graphics in real time. You may be forgetting how much slower CPUs were.
3D interfaces make use of your notion of distance to allow you to see much larger groups of things and understand where they are. Your brain has huge subsystems designed for overview scans, if there is any sort of sane order you'll be able to understand thousands of controls if they are presented to you in a 3D interface. That allows for very complex software.
For example go to the bottom of http://www.huffingtonpost.com/ and click on the links: politics, style... and see how you have no idea where anything is. Do that with a 3D interface and they could present tens of thousands of stories to you in a way that you would in some vague sense be aware of them.
Fair enough I meant it aims at low level high performance languages.
Thank you! That was neat didn't know about that one.
Well you can use info to read man pages and then you'll know those keywords when you need them. :) But yeah texinfo is a pain.
GCC is C. This is a job for a scripting language not a low level compiled language. Typically GNU uses Scheme as their scripting language. But knowledge of Scheme and Scheme syntax is decreasing. Perl has good support for parsing, tons of people know it, It seems like a reasonable choice for GNU to start doing scripting type stuff in. The Perl community has been active with free software for a long time and hasn't gotten involved in anything questionable.
Seems like a reasonable choice.
Nope that predates me that goes back to the days of analog computers. Processing units were parts of a computer where calculations took place. Other parts of the computer might be systems that for example wrote tape to greenbar or the parts that handled input from remote terminal units.
A central processing unit comes from the digital age. It was the unit that contained all the transistor boards that made up the processing unit. Additional processing units might exist in other system but the central one was expensive.
Once you had microprocessing most systems had a single chip responsible for program execution and that took on the name "CPU". Other people continued to refer to the entire box containing the processing transistors as the CPU.
____
And I have no idea what this has to do with me.
Yeah that's a fair characterization. Dell is morphing into 2000 HP. HP is morphing into 2000 EDS.
No partially is the best they decided to do. Project was killed.
As for believing that 0 overhead is the best, that's an argument against GUIs, against hardware abstraction, against OO programming, against dynamic languages... You want maximum hardware efficiency use punchcards or dip switches no OS and program hardware directly in assembly.
I think this reply was meant for me (up one).
I think this is a slightly different argument. Clearly there are some cost savings from the scale of the PC industry. A drop off of 20, 50, 90, 95% is unlikely to have a huge impact on prices because where I think the compensation will come from is in the area of diversity. I.E. there will just be far fewer hardware available. For example when Intel made the 8088 it came in one speed 5mhz. Later they brought out an 8mhz version and you could get it in two speeds.
The 386 came out in: 16, 20, 25, 33 mhz (later called the 386DX) 4 models.
When the chip became far and away the most successful chip ever there were more variants.
We likely return to a situation more like that 95-99.9% drop off. The real issue is whether the rich phone / tablet market then makes PC architecture cost inefficient for the same performance like what happened to SGI, DEC and later Sun. And I don't think so. I think the server market is doing so well that this is unlikely to happen for a very long time.