My McIntosh MC50 Amplifier which I purchased in 1975 has never had a single problem, never once failed. You know why? It was designed by engineers who took pride and care in what they were designing. It was assembled by people who took pride and care in that they were building. Yes it is over 30 years old and still produces and undistorted signal at 50 watts rms into an 8 ohm load.
This paired with a McIntosh C26 pre-amp and mated to a pair of Altec-Lansing Voice of the Theater's or a pair of Klipsch Corner Horns or La Scala's, not only is the sound perfect at very low listening levels, at a mere 50 watts you can be heard 3 blocks away.
We still build quality in this country, but quality is expensive because it requires attention to detail in every stage of the process, from concept to product heading out the shipping bay, and that requires people who are paid well and dedicated to creating a superior product.
It is different because it is not the servers problem, it simply tells the client to also pull down the file in the include tag. The server just serves pure HTML.
Why does it require CMS? Even if I have grown to over 1000 files, they can all be maintained ( each files specific content ) without ever having to use any server side scripting language at all, the web server simply serves HTML files, opens it spews out to the client and thats all it does.
Now I will also agree that when a site grows to a certain point or even depending on the type of site, you will more then likely be serving content from sort sort of DB, but that is not the point. The point is, for a trivial inclusion of one tag, the vast majority of web sites would be well served by that tag. It simplifies site construction and back end systems. Although in this little chain of posts on this subject, I have heard all sorts of alternatives to that tag, I have yet to see a logical argument against that tag. Interesting.
As to breaking things... I think the framset tag was around long before things like google. So did frames break things, or were search engine designers to lazy to come up with a solution? Ehh who knows. But the include tag in HTML would be completely followable by spiders, since the name of the file would be right there, and the search engine could easily present the link in the context that it found it.
But ONLY if the server has mod_ssi linked in. Hence my desire for the <include src="somefile"> tag. The only requirement is that the web server serve pure html, the client then grabs the included file.
BeOS/Haiku Pretty much a hobby OS - I think BeOS was totally cool and it deserved far more support then it got. I still have my BeOS install CD and wish that it had become mainstream because I would be using it now over anything else out there and that includes windows and every flavor of linux/unix.
iPhone I tossed that in with MAC
Never used Solaris and I am not sure what it's gui is based on.
BSD / OpenBSD / FreeBSD / all the rest of the unix clones pretty much use either KDE or Gnome right?
I do it all the time. My point is as pure html the facility to simply include a file should be there. It would be no more difficult then the anchor tag, or the frameset tags and I contend it would be much simpler to implement then either of them.
But again, that puts in a scripting language that must me compiled into the web server.
More and more these days lots of hosting companies don't explicitly set up SSI because of some rare security issues and the overhead that heavy ssi usage can cause.
Since the same amount of data is transfered regardless of the side of the include, I don't see an issue with adding the tag <include src="/somefile.html"/> to the html spec. It takes one more thing off the servers plate.
This biggest issue with the web as I see it, is that we are trying to shoehorn WAY to much into what is essentially desk top publishing API that was designed to do printed material layout, not something interactive. I think we need to abandon that notion and create and actual web 2.0 that is really a lead forward in the ability to design interactive applications that go so far beyond what is currently there.
In addition, I think there needs to be a wholesale rethinking of the notion of the request channel. I mean it works OK but wheb you starting moving lots of data and slamming it into am innerHTML section of some element it just really slows down to the point of being frustrating.
Take for instance a simple one to many record set. The request channel is really pour at this. You can iterate through a set of controls ( your basic parent record ) sending either XML or simple field/value pair and let javascript populate the fields. But when it comes to the sub-records you don't really know how many you have until you run the query. Lets say it generates 10 records. Your server side query knows that, so you can either send the full markup, data and all over the request channel to innerHTML which is can be painfully slow, or you can send a count back, then have javascript generate all the controls and layout, then populate based on ID's like name_01 or something like that, which might even be just as slow.
In any case there has to be a better way to do this.
It has to be a new paradigm and it should be native code of some type.
With the advancement in VM's I think it should be wrappers around the native UI components of the platform that allow for indirect access for security thus preventing the invasion of the control tree, so that things remained sandboxed, yet very fast and looks like the native control set which will always look the best on its own platform.
I know that sounds like a tall order, but when you think about it, there are only really three that have to be taken into account, Windows, Mac and linux ( well kde and gnome ). It would be java like, but because it works by platform, yes a drawback unless a universal binary or PCode system were created
Frames made it very simple to have you web content broken up into nice blocks. You could do all your navigation in one frame, that meant, one file contained your menus. You had one file to edit and you could produce a well defined, well behaved navigation system.
With the jihad against frames we were left with two options:
The menu code had to be reproduced in every file you pulled in. Make a change to the menu system and if you served 1000 different pages, you had to change 1000 files.
Serve it from a database, using php, ruby, perl, python or whatever. Massive complication since you had to build a CMS just to avoid getting smacked down or you had file includes all over the place in those same files, but to have a #include you had to use a scripting language, no more pure HTML for you.
ALL of this could have been solved by having the HTML spec provide a #include tag that would tell the browser to fetch that file eg: but no one seems to like that idea anymore then they likes framsets or iframes
As to Jakob Nielsen saying it breaks the user interface, that guy needs to get over himself in a big way. The web is evolving and changing all the time. As so many have said, the browser is not simply a page reproducer any more, those days are long gone, it has become an application container that allows applications, served from without to run in a defined and "secure" ( we hope ) application space on the local machine.
I for one advocate forking the whole notion. It is time to create and application shell that is specifically designed do just run applications of some specification. I propose that this can be done by making a tag to go along side as the top level tag and call . This would allow the "browser" to take one of two immediate actions:
Start an Application Shell, load and run the app.
Start the HTML rendering engine and display the page.
Further I propose that the navigation portion of be ported out to the browser and you simply load the elements of the menus and it is fed by a separate channel much like XMLhttprequest.
Actually no, I think copyright needs to be seriously reformed, but in the process the following questions need to be asked:
At what point does the creator or owner pf a copyrighted work lose the exclusive right to make copies of and distribute a work covered by copyright law?
What are the consequences for violated that exclusive right? Should they be criminal, civil or both?
What is "fair use" in the digital age?
What is "and archival copy" in the digital age?
What should be covered by copyright law?
Should a copyright be inheritable?
In reference to your fathers actions you mentioned I would think that would be fair use with the caveat that he does then start giving them away to anyone who asked him for a copy. Once he does that, he is not just violating the letter of the law but the spirit as well.
What I most certainly object to is this notion that copyright should be eliminated. Changed yes, eliminated no.
Your argument is both foolish and ill founded and will lead only to escalation.
You have NO right to copy what and author/artist creates and publishes, only the author or their duly appointed agent who compensates the author for every copy of the author's work they produce based upon whatever agreement the author and agent make.
The prevailing attitude of "I can do whatever I want because (fill in your false assumptions and flawed reasoning here)" will only be met by an even harder and progressively harsher reaction if this continues.
As usual the minority screws these things up for the majority. Before the owners of TPB went on trial I predicted they would and the TPB supporters said, "they never will!". When the owners of TPB went on trial I predicted they would be convicted and the TPB supporters said "No Way"
I now predict they will do jail time and have their property seized and sold to satisfy the fines imposed.
One of the companies that I consult has about 3400 desktops running XP is actively in the process of 2 things:
Trying to determine the actual dollar amount and the actual amount of time to get their custom and very mission critical analysis software re-tooled to run on Linux.
Trying to determine if it can even be done and still provide the same quality of user interface and usability that they currently get from XP.
This I find very interesting because this place has been, from their very inception, an "all windows all the time" shop. One day while talking about things with the owner (privately held) I ask him why, given that he was one of the windows faithful? His reply was surprising in as much as he seemed like a religious person who had simply lost his faith.
I think this points to MS weakness of keeping the faithful in the pew as it were. In my mind MS has produced only two really useful bits of software, windows 2000 Professional and Windows XP ( after the eye candy and entertainment bits were removed ) but even then only after several years after they hit the streets.
The future of MS is not in cranking out new and fresh releases of their basic product for entertainment value ( as they are currently doing ) but being more like linux and releasing incremental versions as newer hardware becomes available. I think the delivery schedule needs to be stretched significantly so that these new incremental releases can be tested and vetted before they hit the streets or corporate america for that matter,
You will need at least one Edir Server and they can be the same box ( I Think, it might work with ldap ) and from there you are off and running.
It supports complete logging and log search ability ( by user or full text ), the client supports no other protocols it supports SSL has both linux and windows clients.
It is VERY light weight on both the server and client side.
Sorry, but you are wrong. Don't believe me, ask any lawyer.
Facts vs. Feelings. This is the problem behind nearly every major legal battle that geeks are fighting. The facts support us, people's emotions do not.
They are courts of Law where facts and feelings have very little to do with anything.
it is the answer to the question that no one asked...
In a real world application, as others have mentioned pretty much all of a programs time is spent in an idle loop waiting something to happen and in almost all circumstances it is input from the user in whatever form, mouse, keyboard, etc.
So lets say it is something life Final Cut. Now to be sure when someone kicks of a render this is an operation that can be spun off on its own thread or its own process, freeing up the main process loop to respond to other things that the user might be doing, but that is where the rubber really hits the road is user input. The user could do something that affects the process that was just spun off, either as a separate thread or process on the same core or any other number of cores so you have to keep track of what the user is doing in the context of things that have been farmed out into other cores/processes/threads.
Enter the OS.. Take your pick since it really does not matter which OS we are talking about, they all do the same basic things, perhaps differently, but they do. How does an OS designer make sure any of say 16 cores ( dual 8 core processors) are actually well and fairly utilized? Would it be designed to use a core to handle each of the main functions of the OS, lets say Drive Access, Com Stack pick your protocol here, Video Processing etc., or should it just run a scheduler like those that they now run which farms out thread processing based on priority? Is there really any priority scheme for multiple cores that could run say hundreds of threads / processes each? And what about memory? A single core machine that is say truly 64 bit can handle a very large amount of memory and that single core controls and has access to all that ram at its whim ( DMA not withstanding ), but what do you do now that you have 16 cores all wanting to use that memory, do we create a scheduler to schedule access from 16 different demanding stand alone processors or do we simply give each core a finite memory space and then have to control the movement of data from each memory space to another, since a single process thread ( handling the main UI thread for a program ) has to be aware of when something is finished on one core and then get access to that memory to present results either as data written to say a file or written into video memory for display?
I submit that the current paradigm of SMP is inadequate for these tasks and must be rethought to take advantage of this new hardware. I think a more efficient approach is that each core detected would be fired up with its own monitor stack as a place to start so that the scheduling is based upon the feedback from each core. The monitor program would be able to ensure that the core it is responsible for is optimized for the kind of work that is presented. This concept while complicated could be implemented and serve as a basis for further development in this very complex space.
In the terms of "super computers" this has been dealt with but in a very different methodology that I do not think lends itself to general computing. Deep Blue, Cray's and things like that aren't really relevant in this case since those are mostly very custom designs to handle a single purpose and are optimized for things like Chess or Weather Modeling, Nuclear Weapons study where the problem are already discretely chunked out with a known set of algorithms and processes. General purpose computing on the other hand is like trying to heard cats from the OS point of view since you never really know what is going to be demanded and how.
OS designers and user space software designers need to really break this down and think it all the way through before we get much further or all this silicon is not going to used well or efficiently.
Slashdot Mirror
My McIntosh MC50 Amplifier which I purchased in 1975 has never had a single problem, never once failed. You know why? It was designed by engineers who took pride and care in what they were designing. It was assembled by people who took pride and care in that they were building. Yes it is over 30 years old and still produces and undistorted signal at 50 watts rms into an 8 ohm load.
This paired with a McIntosh C26 pre-amp and mated to a pair of Altec-Lansing Voice of the Theater's or a pair of Klipsch Corner Horns or La Scala's, not only is the sound perfect at very low listening levels, at a mere 50 watts you can be heard 3 blocks away.
We still build quality in this country, but quality is expensive because it requires attention to detail in every stage of the process, from concept to product heading out the shipping bay, and that requires people who are paid well and dedicated to creating a superior product.
It is different because it is not the servers problem, it simply tells the client to also pull down the file in the include tag. The server just serves pure HTML.
Why does it require CMS? Even if I have grown to over 1000 files, they can all be maintained ( each files specific content ) without ever having to use any server side scripting language at all, the web server simply serves HTML files, opens it spews out to the client and thats all it does.
Now I will also agree that when a site grows to a certain point or even depending on the type of site, you will more then likely be serving content from sort sort of DB, but that is not the point. The point is, for a trivial inclusion of one tag, the vast majority of web sites would be well served by that tag. It simplifies site construction and back end systems. Although in this little chain of posts on this subject, I have heard all sorts of alternatives to that tag, I have yet to see a logical argument against that tag. Interesting.
As to breaking things... I think the framset tag was around long before things like google. So did frames break things, or were search engine designers to lazy to come up with a solution? Ehh who knows. But the include tag in HTML would be completely followable by spiders, since the name of the file would be right there, and the search engine could easily present the link in the context that it found it.
But ONLY if the server has mod_ssi linked in. Hence my desire for the <include src="somefile"> tag. The only requirement is that the web server serve pure html, the client then grabs the included file.
BeOS/Haiku Pretty much a hobby OS - I think BeOS was totally cool and it deserved far more support then it got. I still have my BeOS install CD and wish that it had become mainstream because I would be using it now over anything else out there and that includes windows and every flavor of linux/unix.
iPhone I tossed that in with MAC
Never used Solaris and I am not sure what it's gui is based on.
BSD / OpenBSD / FreeBSD / all the rest of the unix clones pretty much use either KDE or Gnome right?
I do it all the time. My point is as pure html the facility to simply include a file should be there. It would be no more difficult then the anchor tag, or the frameset tags and I contend it would be much simpler to implement then either of them.
This is only allowed in the header section as defined by the html spec.
Oh, and your #include tag? That's what a frame is, and what it's supposed to be used for.
Yes I completely understand that, but use frames and just see have many people get their panties in a bunch and start crying fowl.
Consider the simplicity of the following:
<div class ="someclass" id="someid" name="somename"> />
<include src="/menus.html"
</div>
Yes I know about server side includes....
But again, that puts in a scripting language that must me compiled into the web server.
More and more these days lots of hosting companies don't explicitly set up SSI because of some rare security issues and the overhead that heavy ssi usage can cause.
Since the same amount of data is transfered regardless of the side of the include, I don't see an issue with adding the tag <include src="/somefile.html" /> to the html spec. It takes one more thing off the servers plate.
continued from above.
, it would be pretty dang zippy I am thinking.
This biggest issue with the web as I see it, is that we are trying to shoehorn WAY to much into what is essentially desk top publishing API that was designed to do printed material layout, not something interactive. I think we need to abandon that notion and create and actual web 2.0 that is really a lead forward in the ability to design interactive applications that go so far beyond what is currently there.
In addition, I think there needs to be a wholesale rethinking of the notion of the request channel. I mean it works OK but wheb you starting moving lots of data and slamming it into am innerHTML section of some element it just really slows down to the point of being frustrating.
Take for instance a simple one to many record set. The request channel is really pour at this. You can iterate through a set of controls ( your basic parent record ) sending either XML or simple field/value pair and let javascript populate the fields. But when it comes to the sub-records you don't really know how many you have until you run the query. Lets say it generates 10 records. Your server side query knows that, so you can either send the full markup, data and all over the request channel to innerHTML which is can be painfully slow, or you can send a count back, then have javascript generate all the controls and layout, then populate based on ID's like name_01 or something like that, which might even be just as slow.
In any case there has to be a better way to do this.
Yeah Java sucked then, and it still sucks.
It has to be a new paradigm and it should be native code of some type.
With the advancement in VM's I think it should be wrappers around the native UI components of the platform that allow for indirect access for security thus preventing the invasion of the control tree, so that things remained sandboxed, yet very fast and looks like the native control set which will always look the best on its own platform.
I know that sounds like a tall order, but when you think about it, there are only really three that have to be taken into account, Windows, Mac and linux ( well kde and gnome ). It would be java like, but because it works by platform, yes a drawback unless a universal binary or PCode system were created
Frames made it very simple to have you web content broken up into nice blocks. You could do all your navigation in one frame, that meant, one file contained your menus. You had one file to edit and you could produce a well defined, well behaved navigation system.
With the jihad against frames we were left with two options:
ALL of this could have been solved by having the HTML spec provide a #include tag that would tell the browser to fetch that file eg: but no one seems to like that idea anymore then they likes framsets or iframes
As to Jakob Nielsen saying it breaks the user interface, that guy needs to get over himself in a big way. The web is evolving and changing all the time. As so many have said, the browser is not simply a page reproducer any more, those days are long gone, it has become an application container that allows applications, served from without to run in a defined and "secure" ( we hope ) application space on the local machine.
I for one advocate forking the whole notion. It is time to create and application shell that is specifically designed do just run applications of some specification. I propose that this can be done by making a tag to go along side as the top level tag and call . This would allow the "browser" to take one of two immediate actions:
Further I propose that the navigation portion of be ported out to the browser and you simply load the elements of the menus and it is fed by a separate channel much like XMLhttprequest.
Actually no, I think copyright needs to be seriously reformed, but in the process the following questions need to be asked:
What I most certainly object to is this notion that copyright should be eliminated. Changed yes, eliminated no.
Your argument is both foolish and ill founded and will lead only to escalation.
You have NO right to copy what and author/artist creates and publishes, only the author or their duly appointed agent who compensates the author for every copy of the author's work they produce based upon whatever agreement the author and agent make.
The prevailing attitude of "I can do whatever I want because (fill in your false assumptions and flawed reasoning here)" will only be met by an even harder and progressively harsher reaction if this continues.
As usual the minority screws these things up for the majority. Before the owners of TPB went on trial I predicted they would and the TPB supporters said, "they never will!". When the owners of TPB went on trial I predicted they would be convicted and the TPB supporters said "No Way"
I now predict they will do jail time and have their property seized and sold to satisfy the fines imposed.
Lets see if I am 3 for 3
The Balls rocket shoots are quite an event.
Every year they launch from BLM land on the Blackrock dessert. On two days the have FAA clearance to 100,000' MSL
Last year the highest rocket hit 31,000' MSL and hit just pver mach 3. The motor had a burn time of just a little under 4 seconds.
And yes the FAA issues NOTAM's ( Notice to airman ) with the appropriate lat and long for the launch area.
About 10 pm in a tent.
You can hear and see Burning Man from 5 miles distance.
And your company has how many employees -v- IS support staff?
One of the companies that I consult has about 3400 desktops running XP is actively in the process of 2 things:
This I find very interesting because this place has been, from their very inception, an "all windows all the time" shop. One day while talking about things with the owner (privately held) I ask him why, given that he was one of the windows faithful? His reply was surprising in as much as he seemed like a religious person who had simply lost his faith.
I think this points to MS weakness of keeping the faithful in the pew as it were. In my mind MS has produced only two really useful bits of software, windows 2000 Professional and Windows XP ( after the eye candy and entertainment bits were removed ) but even then only after several years after they hit the streets.
The future of MS is not in cranking out new and fresh releases of their basic product for entertainment value ( as they are currently doing ) but being more like linux and releasing incremental versions as newer hardware becomes available. I think the delivery schedule needs to be stretched significantly so that these new incremental releases can be tested and vetted before they hit the streets or corporate america for that matter,
Its not FOSS but it is pretty inexpensive and it is rock solid and scales very very well.
And since E-Directory will install and run on windows,linux,unix and damn near every other OS out there, it is a great option.
You will need at least one Edir Server and they can be the same box ( I Think, it might work with ldap ) and from there you are off and running.
It supports complete logging and log search ability ( by user or full text ), the client supports no other protocols it supports SSL has both linux and windows clients.
It is VERY light weight on both the server and client side.
Where is the Pointlessly-Clueless when you need it.
Sorry, but you are wrong. Don't believe me, ask any lawyer.
Facts vs. Feelings. This is the problem behind nearly every major legal battle that geeks are fighting. The facts support us, people's emotions do not.
They are courts of Law where facts and feelings have very little to do with anything.
You mean aside from the part about you lying through your teeth?
It's just fine.. <snide grin>
Who could forget...
go atasci-ii or go away!
it is the answer to the question that no one asked...
In a real world application, as others have mentioned pretty much all of a programs time is spent in an idle loop waiting something to happen and in almost all circumstances it is input from the user in whatever form, mouse, keyboard, etc.
So lets say it is something life Final Cut. Now to be sure when someone kicks of a render this is an operation that can be spun off on its own thread or its own process, freeing up the main process loop to respond to other things that the user might be doing, but that is where the rubber really hits the road is user input. The user could do something that affects the process that was just spun off, either as a separate thread or process on the same core or any other number of cores so you have to keep track of what the user is doing in the context of things that have been farmed out into other cores/processes/threads.
Enter the OS.. Take your pick since it really does not matter which OS we are talking about, they all do the same basic things, perhaps differently, but they do. How does an OS designer make sure any of say 16 cores ( dual 8 core processors) are actually well and fairly utilized? Would it be designed to use a core to handle each of the main functions of the OS, lets say Drive Access, Com Stack pick your protocol here, Video Processing etc., or should it just run a scheduler like those that they now run which farms out thread processing based on priority? Is there really any priority scheme for multiple cores that could run say hundreds of threads / processes each? And what about memory? A single core machine that is say truly 64 bit can handle a very large amount of memory and that single core controls and has access to all that ram at its whim ( DMA not withstanding ), but what do you do now that you have 16 cores all wanting to use that memory, do we create a scheduler to schedule access from 16 different demanding stand alone processors or do we simply give each core a finite memory space and then have to control the movement of data from each memory space to another, since a single process thread ( handling the main UI thread for a program ) has to be aware of when something is finished on one core and then get access to that memory to present results either as data written to say a file or written into video memory for display?
I submit that the current paradigm of SMP is inadequate for these tasks and must be rethought to take advantage of this new hardware. I think a more efficient approach is that each core detected would be fired up with its own monitor stack as a place to start so that the scheduling is based upon the feedback from each core. The monitor program would be able to ensure that the core it is responsible for is optimized for the kind of work that is presented. This concept while complicated could be implemented and serve as a basis for further development in this very complex space.
In the terms of "super computers" this has been dealt with but in a very different methodology that I do not think lends itself to general computing. Deep Blue, Cray's and things like that aren't really relevant in this case since those are mostly very custom designs to handle a single purpose and are optimized for things like Chess or Weather Modeling, Nuclear Weapons study where the problem are already discretely chunked out with a known set of algorithms and processes. General purpose computing on the other hand is like trying to heard cats from the OS point of view since you never really know what is going to be demanded and how.
OS designers and user space software designers need to really break this down and think it all the way through before we get much further or all this silicon is not going to used well or efficiently.