That being said, I did learn something of great import while in undergrad. After getting mediocre grades throughout I somehow matured a little bit and taught myself how to learn. This was the most important thing I got out of undergrad.
The part about this that I find so frustrating is that it's such an expensive lesson for kids. I was a home schooler myself, and my mother constantly emphasized that what we learned was less important than learning *how* to learn. While I'm sure that many would take that to mean that she didn't teach us, nothing could be farther from the truth. Rather, I *wanted* to learn many subjects because I had practical uses for them outside of the classroom.
Do you have any idea how cool it is to look at a Trig book and think, "Oh, the raycasting engines I can make with this baby...":-)
Mod parent up. He's a perfect example of what I'm talking about. Higher education is about learning what you know you want to learn. If you don't have a desire to be there, then you shouldn't.:-)
Of course, your post completely ignores the real issue: That they shouldn't have gone to college in the first place.
The US has gotten so fixated on sending kids to college that we've lost sight of the reasons why we wanted them there in the first place. As a result, the quality of education has been declining, while the amount of debt our kids pile up before ever starting a job has been rising. And how many of those kids use their college degrees to do amazing things like sell real estate or become plumbers. i.e. What did that degree buy them other than a wad of debt?
That's not to say that education is a bad thing. But people always get the best bang out of an education when they know they want it. Sending them to school before they know what they want to know only devalues it for everyone. Teach your kids to wait until they're ready. Then they can be sure that they really want to take on a college education.
In summary, Linux Torvalds understands that computers are about the right tool for the right job. For some, that tool is Linux. For others, that tool is *BSD. But he rightfully takes the stance that competition is no skin off his nose.
This is a *good* thing people! I realize it's much easier to jump into Highlander mode ("There can be only one!"), but reality is rarely so simple. Until someone invents the "perfect solution", every decision will lead to a particular set of tradeoffs. If you don't have anyone else exploring alternatives, how can you know for certain that your own alternative is the best one? Cooperation always leads to better results.
That said, I have a feeling about the replies I'm about to get:
Girl: Don't even think about it! Human Torch: Never do. (Jumps off building) Human Torch: Flame ON!;-P
Sorry, but you're full of it. There is nothing FUD about my post unless you really think that OOo 2.0, GCC 4.0, and other features are well out of Beta. (Hint: They're not.) Fedora has done a pretty good job of keeping things internally consistent, but that doesn't mean that it's for everyone. Or that all of the features are in place. (e.g. One of the most frustrating RedHat experiences I ever had was when I realized that the GNOME Desktop folders were stored in different places across every version, and that user specific shortcuts either didn't work, or worked in a broken kind of way.)
While I like Apple's designs, that doesn't meant that I have anything against Linux. Fedora is what it is, and users have a right to be warned when they are dealing with a potentially hot potato.
I don't know about the original poster, but I live in downtown Chicago.
Pizza Hut's website does online orders for delivery everywhere I've been.
Pizza Hut won't deliver to me. They claim I'm right outside of their range.
Other Pizza places have actually been devolving, with one of my favorites no longer using a phone number database. (You hear me Donnie's!?! We LIKED not having to give you info every time!)
There are, of course, plenty of places that will ship you a Pizza via UPS/FedEx.
And Chinese, deli, kosher, grilled, and all kinds of other foods have delivery service once you order over the phone.
I'd love to know where these are. I've got China town sitting a few blocks away, and yet the restaurants there can barely take my order over the phone, much less Internet.:-/
I'm not sure of the geography of Nevada or Utah, but Texas has a coast and a big gulf full of splashdown area.
That was my first thought as well, but upon further reflection it doesn't hold much water. (ha ha) The craft is designed for suborbital hops that involve vertical take off and landing on dry land. Without better knowing the flight profile, it's always hard to say, but it doesn't appear that this craft ever passes over water. It just goes straight up and comes back down.
So what else is in Texas that might of interest? Maybe another team working on the exact same technology? Hmmm...;-)
To anyone thinking of downloading this, be warned that these are bleeding edge features! Fedora is the first place they often get tested, and they don't always fit together smoothly. Not to mention that many individual features are not out of Beta testing! So only use this distro if you don't mind getting burned a little bit!
Otherwise it can be a great way to understand what is coming down the pipe.:-)
P.S. Parent poster forgot about GCC 4.0. That's a MAJOR feature itself, but also one of easiest to get burned by.
Jeff Bezos, the Amazon guy, has a space company? That's plenty of revelation for me!
It may not be as surprising as you think:
The Blue Origin RLV would be comprised of a propulsion module and a crew capsule and would use hydrogen peroxide and kerosene as propellants.
The RLV would launch vertically from a concrete pad and would land vertically in an area near the launch pad.
The RLV would carry three or more passengers per operation.
Blue Origin proposes to locate its launch facility on privately-owned property in Culberson County, Texas.
Now maybe I'm missing something, but doesn't this sound a LOT like the Aramadillo Aerospace craft? And why Texas? Nevada or Utah are closer to Mr. Bezos and probably have cheaper land. Not to mention that the specs on this thing align perfectly with the X-Prize goals. Now I realize that Armadillo has officially moved on to LHOx propellant, but perhaps they sold off their old technology? And LHOx is only a necessary fuel if the craft is planning to go orbital. For suborbital flights, far less powerful rockets are required.
Mr. Caramack or Mr. Bezos, if you're reading this, how about giving us the 411?
Re:Which is the bigger irony:
on
Ajax On Rails
·
· Score: 1
I stand corrected, then.:-)
Re:Which is the bigger irony:
on
Ajax On Rails
·
· Score: 2, Interesting
Then Microsoft created XMLHttpRequest in Internet Explorer 5, which let browser-side JavaScript communicate with the web server in the background without requiring the browser to display a new web page.
This isn't quite correct. IFrame and hidden IFrame communication was invented before that. The catch is that browsers weren't stable enough or compatible enough to make use of these channels.
XMLHttpRequest does more or less the same thing as an IFrame (via an ActiveX contarol), except that it adds the overhead of an XML parse. AFAIK, Google doesn't use the XMLHttpRequest for any of their applications.
(a) Darwin is not FreeBSD, nor is it directly derived from FreeBSD.
Having spent some time researching the topic, I have found this to be just as untrue of a statement as "Darwin is basically FreeBSD!"
As with many things, the truth lies somewhere in the middle. You see, Darwin is based on the Mach kernel, a design intended to improve the state of Operating System research, but not an OS unto itself. Mach was actually built on top of BSD 4.3, as the researchers considered the basic kernel duties to be irrelevant to their research.
When NeXT was ported to the Apple Macintosh, the decision was made to update to a codebase newer than BSD 4.3. The choice that was made at the time was FreeBSD. As a result, Darwin is currently a half-FreeBSD, half-Mach hybrid that contains many of the FreeBSD kernel constructs, but is supercharged with the Mach message-passing semantics.
The command line utilities are used from FreeBSD both because they are very Unix-ish implementations, and because using them is convenient.
OS X is not free or open source, and only Apple gets to choose what goes in it.
Scott McNealy did a very good writeup a few years ago in which he encouraged companies to release non-core software into open source. His justification was that software that wasn't giving you a competitive advantage was just a cost that could be reduced by letting volunteers help. However, software that gave you a competitive advantage in the market should be kept closed for as long as that advantage is maintained.
That is what Apple has done. Darwin, Safari, and other non-critical components are open. Quartz, Cocoa, IOKit, and other competitive advantages are kept closed. Seems to me that Apple is playing the game quite well.:-)
When it comes to portable code, OS X offers only the basic POSIX functions. If you want to use a non-proprietary library that's not included in the OS X BSD subsystem, guess what? The situation's just like Linux - except that it's a pain in the ass to package your application for OS X, while it's dead easy to package it for Linux or Windows.
Except that your point is irrelevant. Linux systems use open APIs that are considered quite portable. The issue at hand is that the exact mix of available APIs is constantly changing and unpredictable, even on a single distro. If distros took the tack of creating a stable API base each revision (similar to how Windows and OS X work), then could become far more attractive to users.
A library is *not* a library. First off, if you depend on anything except the system libraries, you're on your own.
I assume you mean "on your own" from the perspective of XCode not supporting you? Because GCC is still GCC on both systems.
And if you use the system libraries, you must ensure that you target a specific OS release version, and you have minimal resources at hand to allow you to target previous versions.
You make it sound like a bad thing. Progress forward is a *good* thing. The argument here is more about the issues inherent in going forward. In Mac OS X, going forward is rarely a problem. In Linux, packaging errors can commonly build up and cause issues.
Yes, you can just package everything in your app bundle. This is a stupid wasteful solution and there's a reason people prefer dynamic libraries.
It's only wasteful if it's truely something that everyone else will be using. The problem is that the majority of the libaries you use outside the core are not going to be used by other programs on your hard drive. At best, you may find one more. That makes the amount of waste minimal, and improves the user experience overall. If a given API ends up used in a large number of programs, then the vendor should add it to the next OS release.
A packaging system provides tools so the user and the developler work together to solve them.
The problem is that dependency issues should never be the user's problem. Dependencies tend to be a shortcut developers take so that they don't have to reinvent the wheel. That's a good thing. But if you're forcing the user to worry about your development habits, then the user is going to get pretty upset.
On OS X, I can't update my version of WebCore to get some of the new fixes I want. I can't do this because my applications will break.
Indeed. The same thing often happens on Linux. If you upgrade GLib, you may just break a large number of existing applications. Yet if you don't upgrade, the new applications you want to install won't work. Having an API basis per version at least forces the developer to make due with what exists, or wait to release his software until the next version.
System libraries are not considered upgradable by the user. This is totally opposite to the Linux culture where upgrading is considered a normal, acceptable activity, and there are tools and methodolgies in place to assist it.
That's my entire point. Upgrading system components is BAD for the user. And since the developer is supposed to serve the user, it's BAD overall. The only upgrades that should ever be done to the core (short of an entire platform upgrade) is security fixes and OS patches. None of which should ever affect the APIs available or the behavior of the system.
So the question on everyone's minds at this point is: What *will* Longhorn actually have in it? Avalon, Indigo, and WinFX are all being backported to XP/2003, WinFS has been dropped for the release, and now Monad (I love that name) is being cut. I'm not quite sure how Microsoft plans to sell the OS on such exciting features as "Better DRM!" and "We've got the security thing right this time. Promise!"
"It will take three to five years to fully develop and deliver," said Microsoft Senior Vice President Bob Muglia this week at Tech Ed 2005.
*Jaw hits the floor*
Five years? Whoa. Five years ago, Windows 2000 was brand new. Five years ago, Mac users were still stuck with OS 9. Five years ago, the tech boom was still on. Five years ago, Bill Clinton was still President. Even worse is that Win32 is only ten years old!
If it takes Microsoft five years to get something out the door, I think they will soon find themselves becoming irrelevant in the desktop market. Confidence can be a good thing, but over-confidence can mean disaster. The bright side to this is that users will win when Microsoft is forced to go back to being an applications vendor instead of an OS vendor. Maybe they'll even get around to making another BASIC that doesn't suck.;-)
On a slightly different topic, I really think that Microsoft is really on the wrong track with their combined Desktop/Server codebase bent. As technology marches on, Microsoft will quickly find that their competitors are taking advantage of technological solutions that only make sense on one side of the fence. I have to wonder if some of the delay that we're seeing isn't caused by Microsoft attempting to make all of their technology work in both arenas.
As a developer, the OS X solution sucks ass. It doesn't work. And the packaging one does. So what it tells *me* is that packaging is better.
Now there's a new one. As a developer, I find the solution about equal. A library is a library. In the case of OS X, I have a bunch of great APIs already available to me. In the case of Linux, I have to download and compile my own. The key difference is in distribution where we start overlapping with users. As a developer, I have to *hope* that a Linux user gets the right packages installed. On a Mac, this issue does not exist.
As a user, they're exactly the same except that I get to choose when I want to update from upstream instead of only getting it when Apple says it's okay
Now that's just a lie no matter which way you cut it. On OS X I simply check my system version against the required one. If they match, I download and run the application. No installation required. On Linux, I must first resolve all the dependencies and ensure that all the packages are installed. This works great for the first month or two of the distro's release, but as programs start appearing who's dependencies can't be automatically updated, I begin having to manually fix errors that are preventing a package from being installed. And I have to be careful, because the fix might prevent an existing package from working correctly. All because the core of the system can get upgraded and break the delicate balance of dependencies.
You've described the situation pretty much to a T. And yet (amazingly) the OS X solution works, but the packaging solution doesn't. Shouldn't that tell us something?
You can't put libraries inside an OSX app without ugly hacks manually updating LD_LIBRARY_PATH, and if you have multiple executables to run that isn't going to work.. for proper installation they need to go in/usr/lib or/usr/local/lib, with your binary in/usr/bin just like any other applicaiton/
But you can statically link them. It's effectively the same result. A Linux system based on the AppFolder concept could easily fix this oversight if so desired.
if you have a larger application it just doesn't work to do that - you need a proper installer.
That's why if you install most Apple programs they don't in fact use the drag/drop metaphor at all - they install to fixed places on the hard disk like any other installer.
This is patent nonsense, and I wish that people would stop repeating it. I've used an OS X system for about two years now, and the only installers were for Unix command line components, "portable" Java installers, system updates, and that's about it. Pretty much ALL OS X apps come in an appfolder. The few that don't tend to just build an APP file anyway. Most of those were from earlier versions where the vendor wanted to pop up a EULA before allowing the software to be run. DMGs now support the ability to show a license on open, so this issue has mostly gone by-the-by.
Don't believe everything you read. It may be FUD.;-)
The point is, the world constantly changes and progresses. You cannot isolate a large system of interest from external developments, so stop trying. It would be nice if all package installations went smoothly, but not nice enough to justify using Gnome 0.6 for all eternity.
Now you're just being silly. Is OS X isolated from outside developments? No. Because the entire system core moves as one large piece. The applications are more dynamic, but they always are targetted directly at a minimum system level. This is different from Linux where Debian Woody can mean different things to different people depending on how many updates they've done from the repository. One system could be GLib 2.1, while another could be GLib 2.5*. An application may then refuse to install either because you don't have a new enough version of GLib, or because your version is too new!
If a system core moves at as all or nothing standard, then this issue doesn't exist. If a program needs an API that isn't included in the core, it can bundle it. The user's life is easier, and the system maintainer's lives are easier.
* Made up version numbers. I don't remember what the real ones are.
Circular dependencies are not a problem - if you view the set of packages and their dependencies as a directed finite graph - it's easy to come up with an algorithm for reliably figuring out the closure of dependency relations for any given package or set of packages.
Exactly! You're thinking right along the same lines I am. The key is to view the system as a whole, because that is how it will operate. Once the system *is* whole, then many of the circular dependency issues go away. It's only through the concept of componetizing dependent components that we arrive at the issues common to packaging systems. What we really need to work out is how it might be possible to create a distribution system that doesn't exhibit these issues.
My thought is that a system core that can be treated as a whole is half the solution. The other half is discrete applications that don't attempt to upgrade the core, and keep all non-core APIs to themselves. If a particular library starts popping up across several applicaitons, it can then be added to a future version of the OS core.:-)
They also don't have the resources to making security patches for every package without upgrading to a newer version of said package (i.e. backporting). They really do a phenominal job given their constraints.
I agree wholeheartedly. I'm not attempting to "diss" the Debian distro or its maintainers. I'm only pointing out that the packaging system is beginning to strain under the pressure of so many packages. The complexity of the package system is quickly becoming too difficult to maintain. Especially since the packaging system mixes the core system APIS with the user applications. (Always a recipe for trouble.) Thus it is time to start thinking about something new.
The Linux Standard Base is dead.
The LSB was always about the "least common denominator" and not about "the most usable configuration". For what it was, it wasn't too bad. But a real standard at this point would have to define a lot more libraries, although perhaps at more of a library version level than trying to force the individual APIs.
With that in mind, I don't think that such a standard should be attempted across all distros. For one, that would limit their ability to be different and provide new competitive services. For another, it tends to be better to allow a few different standards to compete before you attempt to pick one or two out of the fold. For example, there used to be many standards for Linus base distros. Now all distros tend to fork from either RedHat or Debian. Standards thus emerged.
The same thing should happen today. We should see different distros attempt differing solutions to the issue and see which ones work best. Symphony is certainly one of the most interesting, but mostly because it's the first attempt to break away from the current designs that Linux is stuck in.:-)
Chief among the problems, he said, were cyclic dependencies and the fact that software installation tool apt depended heavily on the changing C++ libraries.
Let this be a lesson to those of you who claimed that "APT is unbreakable." There's no such thing as an unbreakable technology. There is however, such a thing as a robust technology that resists failure. As packaging systems go, APT is fairly good. However, my belief is that packaging systems are inherently flawed.
What you want in an OS, is a method for determining the precise core upon which you can base your applications on. Such a core would effectively be an immutable set of system APIs that cannot be changed. The upshot to this situation is that the given system is verifyable. i.e. I can have a script go through and ensure that everything that should exist does exist. From that information, I can then do a delta to find out what exists that shouldn't exist.
This is in direct opposition to a packaging system that builds an OS out of inter-dependent components. The problem with such a strategy is that using inter-dependent components only works if you're building from scratch. As anyone who has managed a version control system can tell you, things get extremely complicated (and tend to require manual intervention) as soon as files start branching. The same thing happens in packaging systems as soon as you start doing upgrades to individual components. Soon you find yourself with a mess of mismatched dependencies which require constant manual intervention to solve. Not a good situation.
In the case of a defined core, you can simply wipe out the old core and replace it with the new one. As long as testing has been done to ensure that the new components are still backward compatible with old software, everything should work fine after the upgrade.
Food for thought, anyway. To the Debian team: Thanks for the new release! Even if there are some growing pains, it's still nice to see you back in the game.:-)
- How do you set a static path to a file, when several have the same name ? Live queries are moving targets. Unique IDs are not enough IMHO.
Node IDs work more than well enough for OS X. They are core to the IOKit, and as a result all programs support them.
- Interoperability between systems become a nightmare
How so? A stream of bytes with a name is still a stream of bytes with a name. The meta data is additional information on top of that.
- How do you manage a trashcan ? More importantly, how do you manage the trashcan without confusing the user ?
Simple, just like today. Trash cans would be a single area full of the files that were deleted. As with most trashcans, the view is flat. All attributes would be restored if the file were restored.
- Most normal users have BIG problems understanding how to make good queries in Google, but all of this suppose they will become proficient at making queries, and I have serious doubts about that
Well, labelling and stored file searching are two methods for accomplishing the same thing. Labelling works a bit like folders do today, while stored queries provide the user with a more free-form method. If you don't feel comfortable with saved queries, don't use them. However, I think you'll find the concept straight forward enough. e.g. Search for "Movies" and you'll get all your movies.
- How do you manage your pile of queries, once you have tens of them ? (I guess you don't, what a horrible mess)
Spotlight allows you to create "Smart Folders". These look like regular folders but are actually saved queries that execute when you access them. In practice, they should be no more messy than a regular set of folders.
- Where do you save a document ? I mean, you save it, you don't know where, but how do you get it back ? For example, you save it with Word 2003. Now you want to use Word 2005, or, say OOo. How do you do that ?
Save it to one of the media options on your computer. Instead of folders on the given media, you should see a list of Labels that you can attach. An unlabeled file will show up in the root folder.
Slashdot Mirror
That being said, I did learn something of great import while in undergrad. After getting mediocre grades throughout I somehow matured a little bit and taught myself how to learn. This was the most important thing I got out of undergrad.
:-)
The part about this that I find so frustrating is that it's such an expensive lesson for kids. I was a home schooler myself, and my mother constantly emphasized that what we learned was less important than learning *how* to learn. While I'm sure that many would take that to mean that she didn't teach us, nothing could be farther from the truth. Rather, I *wanted* to learn many subjects because I had practical uses for them outside of the classroom.
Do you have any idea how cool it is to look at a Trig book and think, "Oh, the raycasting engines I can make with this baby..."
Mod parent up. He's a perfect example of what I'm talking about. Higher education is about learning what you know you want to learn. If you don't have a desire to be there, then you shouldn't. :-)
Of course, your post completely ignores the real issue: That they shouldn't have gone to college in the first place.
The US has gotten so fixated on sending kids to college that we've lost sight of the reasons why we wanted them there in the first place. As a result, the quality of education has been declining, while the amount of debt our kids pile up before ever starting a job has been rising. And how many of those kids use their college degrees to do amazing things like sell real estate or become plumbers. i.e. What did that degree buy them other than a wad of debt?
That's not to say that education is a bad thing. But people always get the best bang out of an education when they know they want it. Sending them to school before they know what they want to know only devalues it for everyone. Teach your kids to wait until they're ready. Then they can be sure that they really want to take on a college education.
In summary, Linux Torvalds understands that computers are about the right tool for the right job. For some, that tool is Linux. For others, that tool is *BSD. But he rightfully takes the stance that competition is no skin off his nose.
;-P
This is a *good* thing people! I realize it's much easier to jump into Highlander mode ("There can be only one!"), but reality is rarely so simple. Until someone invents the "perfect solution", every decision will lead to a particular set of tradeoffs. If you don't have anyone else exploring alternatives, how can you know for certain that your own alternative is the best one? Cooperation always leads to better results.
That said, I have a feeling about the replies I'm about to get:
Girl: Don't even think about it!
Human Torch: Never do. (Jumps off building)
Human Torch: Flame ON!
Sorry, but you're full of it. There is nothing FUD about my post unless you really think that OOo 2.0, GCC 4.0, and other features are well out of Beta. (Hint: They're not.) Fedora has done a pretty good job of keeping things internally consistent, but that doesn't mean that it's for everyone. Or that all of the features are in place. (e.g. One of the most frustrating RedHat experiences I ever had was when I realized that the GNOME Desktop folders were stored in different places across every version, and that user specific shortcuts either didn't work, or worked in a broken kind of way.)
While I like Apple's designs, that doesn't meant that I have anything against Linux. Fedora is what it is, and users have a right to be warned when they are dealing with a potentially hot potato.
Sucks to live where you do.
:-/
I don't know about the original poster, but I live in downtown Chicago.
Pizza Hut's website does online orders for delivery everywhere I've been.
Pizza Hut won't deliver to me. They claim I'm right outside of their range.
Other Pizza places have actually been devolving, with one of my favorites no longer using a phone number database. (You hear me Donnie's!?! We LIKED not having to give you info every time!)
There are, of course, plenty of places that will ship you a Pizza via UPS/FedEx.
And Chinese, deli, kosher, grilled, and all kinds of other foods have delivery service once you order over the phone.
I'd love to know where these are. I've got China town sitting a few blocks away, and yet the restaurants there can barely take my order over the phone, much less Internet.
I'm not sure of the geography of Nevada or Utah, but Texas has a coast and a big gulf full of splashdown area.
;-)
That was my first thought as well, but upon further reflection it doesn't hold much water. (ha ha) The craft is designed for suborbital hops that involve vertical take off and landing on dry land. Without better knowing the flight profile, it's always hard to say, but it doesn't appear that this craft ever passes over water. It just goes straight up and comes back down.
So what else is in Texas that might of interest? Maybe another team working on the exact same technology? Hmmm...
To anyone thinking of downloading this, be warned that these are bleeding edge features! Fedora is the first place they often get tested, and they don't always fit together smoothly. Not to mention that many individual features are not out of Beta testing! So only use this distro if you don't mind getting burned a little bit!
:-)
Otherwise it can be a great way to understand what is coming down the pipe.
P.S. Parent poster forgot about GCC 4.0. That's a MAJOR feature itself, but also one of easiest to get burned by.
Jeff Bezos, the Amazon guy, has a space company? That's plenty of revelation for me!
It may not be as surprising as you think:
The Blue Origin RLV would be comprised of a propulsion module and a crew capsule and would use hydrogen peroxide and kerosene as propellants.
The RLV would launch vertically from a concrete pad and would land vertically in an area near the launch pad.
The RLV would carry three or more passengers per operation.
Blue Origin proposes to locate its launch facility on privately-owned property in Culberson County, Texas.
Now maybe I'm missing something, but doesn't this sound a LOT like the Aramadillo Aerospace craft? And why Texas? Nevada or Utah are closer to Mr. Bezos and probably have cheaper land. Not to mention that the specs on this thing align perfectly with the X-Prize goals. Now I realize that Armadillo has officially moved on to LHOx propellant, but perhaps they sold off their old technology? And LHOx is only a necessary fuel if the craft is planning to go orbital. For suborbital flights, far less powerful rockets are required.
Mr. Caramack or Mr. Bezos, if you're reading this, how about giving us the 411?
I stand corrected, then. :-)
Then Microsoft created XMLHttpRequest in Internet Explorer 5, which let browser-side JavaScript communicate with the web server in the background without requiring the browser to display a new web page.
This isn't quite correct. IFrame and hidden IFrame communication was invented before that. The catch is that browsers weren't stable enough or compatible enough to make use of these channels.
XMLHttpRequest does more or less the same thing as an IFrame (via an ActiveX contarol), except that it adds the overhead of an XML parse. AFAIK, Google doesn't use the XMLHttpRequest for any of their applications.
(a) Darwin is not FreeBSD, nor is it directly derived from FreeBSD.
:-)
Having spent some time researching the topic, I have found this to be just as untrue of a statement as "Darwin is basically FreeBSD!"
As with many things, the truth lies somewhere in the middle. You see, Darwin is based on the Mach kernel, a design intended to improve the state of Operating System research, but not an OS unto itself. Mach was actually built on top of BSD 4.3, as the researchers considered the basic kernel duties to be irrelevant to their research.
When NeXT was ported to the Apple Macintosh, the decision was made to update to a codebase newer than BSD 4.3. The choice that was made at the time was FreeBSD. As a result, Darwin is currently a half-FreeBSD, half-Mach hybrid that contains many of the FreeBSD kernel constructs, but is supercharged with the Mach message-passing semantics.
The command line utilities are used from FreeBSD both because they are very Unix-ish implementations, and because using them is convenient.
OS X is not free or open source, and only Apple gets to choose what goes in it.
Scott McNealy did a very good writeup a few years ago in which he encouraged companies to release non-core software into open source. His justification was that software that wasn't giving you a competitive advantage was just a cost that could be reduced by letting volunteers help. However, software that gave you a competitive advantage in the market should be kept closed for as long as that advantage is maintained.
That is what Apple has done. Darwin, Safari, and other non-critical components are open. Quartz, Cocoa, IOKit, and other competitive advantages are kept closed. Seems to me that Apple is playing the game quite well.
When it comes to portable code, OS X offers only the basic POSIX functions. If you want to use a non-proprietary library that's not included in the OS X BSD subsystem, guess what? The situation's just like Linux - except that it's a pain in the ass to package your application for OS X, while it's dead easy to package it for Linux or Windows.
Except that your point is irrelevant. Linux systems use open APIs that are considered quite portable. The issue at hand is that the exact mix of available APIs is constantly changing and unpredictable, even on a single distro. If distros took the tack of creating a stable API base each revision (similar to how Windows and OS X work), then could become far more attractive to users.
A library is *not* a library. First off, if you depend on anything except the system libraries, you're on your own.
I assume you mean "on your own" from the perspective of XCode not supporting you? Because GCC is still GCC on both systems.
And if you use the system libraries, you must ensure that you target a specific OS release version, and you have minimal resources at hand to allow you to target previous versions.
You make it sound like a bad thing. Progress forward is a *good* thing. The argument here is more about the issues inherent in going forward. In Mac OS X, going forward is rarely a problem. In Linux, packaging errors can commonly build up and cause issues.
Yes, you can just package everything in your app bundle. This is a stupid wasteful solution and there's a reason people prefer dynamic libraries.
It's only wasteful if it's truely something that everyone else will be using. The problem is that the majority of the libaries you use outside the core are not going to be used by other programs on your hard drive. At best, you may find one more. That makes the amount of waste minimal, and improves the user experience overall. If a given API ends up used in a large number of programs, then the vendor should add it to the next OS release.
A packaging system provides tools so the user and the developler work together to solve them.
The problem is that dependency issues should never be the user's problem. Dependencies tend to be a shortcut developers take so that they don't have to reinvent the wheel. That's a good thing. But if you're forcing the user to worry about your development habits, then the user is going to get pretty upset.
On OS X, I can't update my version of WebCore to get some of the new fixes I want. I can't do this because my applications will break.
Indeed. The same thing often happens on Linux. If you upgrade GLib, you may just break a large number of existing applications. Yet if you don't upgrade, the new applications you want to install won't work. Having an API basis per version at least forces the developer to make due with what exists, or wait to release his software until the next version.
System libraries are not considered upgradable by the user. This is totally opposite to the Linux culture where upgrading is considered a normal, acceptable activity, and there are tools and methodolgies in place to assist it.
That's my entire point. Upgrading system components is BAD for the user. And since the developer is supposed to serve the user, it's BAD overall. The only upgrades that should ever be done to the core (short of an entire platform upgrade) is security fixes and OS patches. None of which should ever affect the APIs available or the behavior of the system.
Microsoft Barbie says "Writing Operating Systems is HARD!"
Indeed. But writing command line shells? *jaw hits the floor again*
So the question on everyone's minds at this point is: What *will* Longhorn actually have in it? Avalon, Indigo, and WinFX are all being backported to XP/2003, WinFS has been dropped for the release, and now Monad (I love that name) is being cut. I'm not quite sure how Microsoft plans to sell the OS on such exciting features as "Better DRM!" and "We've got the security thing right this time. Promise!"
;-)
"It will take three to five years to fully develop and deliver," said Microsoft Senior Vice President Bob Muglia this week at Tech Ed 2005.
*Jaw hits the floor*
Five years? Whoa. Five years ago, Windows 2000 was brand new. Five years ago, Mac users were still stuck with OS 9. Five years ago, the tech boom was still on. Five years ago, Bill Clinton was still President. Even worse is that Win32 is only ten years old!
If it takes Microsoft five years to get something out the door, I think they will soon find themselves becoming irrelevant in the desktop market. Confidence can be a good thing, but over-confidence can mean disaster. The bright side to this is that users will win when Microsoft is forced to go back to being an applications vendor instead of an OS vendor. Maybe they'll even get around to making another BASIC that doesn't suck.
On a slightly different topic, I really think that Microsoft is really on the wrong track with their combined Desktop/Server codebase bent. As technology marches on, Microsoft will quickly find that their competitors are taking advantage of technological solutions that only make sense on one side of the fence. I have to wonder if some of the delay that we're seeing isn't caused by Microsoft attempting to make all of their technology work in both arenas.
As a developer, the OS X solution sucks ass. It doesn't work. And the packaging one does. So what it tells *me* is that packaging is better.
Now there's a new one. As a developer, I find the solution about equal. A library is a library. In the case of OS X, I have a bunch of great APIs already available to me. In the case of Linux, I have to download and compile my own. The key difference is in distribution where we start overlapping with users. As a developer, I have to *hope* that a Linux user gets the right packages installed. On a Mac, this issue does not exist.
As a user, they're exactly the same except that I get to choose when I want to update from upstream instead of only getting it when Apple says it's okay
Now that's just a lie no matter which way you cut it. On OS X I simply check my system version against the required one. If they match, I download and run the application. No installation required. On Linux, I must first resolve all the dependencies and ensure that all the packages are installed. This works great for the first month or two of the distro's release, but as programs start appearing who's dependencies can't be automatically updated, I begin having to manually fix errors that are preventing a package from being installed. And I have to be careful, because the fix might prevent an existing package from working correctly. All because the core of the system can get upgraded and break the delicate balance of dependencies.
You've described the situation pretty much to a T. And yet (amazingly) the OS X solution works, but the packaging solution doesn't. Shouldn't that tell us something?
Please, try to be civil. Allowing the discussion to degrade to a flamewar won't help anyone.
You can't put libraries inside an OSX app without ugly hacks manually updating LD_LIBRARY_PATH, and if you have multiple executables to run that isn't going to work.. for proper installation they need to go in /usr/lib or /usr/local/lib, with your binary in /usr/bin just like any other applicaiton/
;-)
But you can statically link them. It's effectively the same result. A Linux system based on the AppFolder concept could easily fix this oversight if so desired.
if you have a larger application it just doesn't work to do that - you need a proper installer.
That's why if you install most Apple programs they don't in fact use the drag/drop metaphor at all - they install to fixed places on the hard disk like any other installer.
This is patent nonsense, and I wish that people would stop repeating it. I've used an OS X system for about two years now, and the only installers were for Unix command line components, "portable" Java installers, system updates, and that's about it. Pretty much ALL OS X apps come in an appfolder. The few that don't tend to just build an APP file anyway. Most of those were from earlier versions where the vendor wanted to pop up a EULA before allowing the software to be run. DMGs now support the ability to show a license on open, so this issue has mostly gone by-the-by.
Don't believe everything you read. It may be FUD.
The point is, the world constantly changes and progresses. You cannot isolate a large system of interest from external developments, so stop trying. It would be nice if all package installations went smoothly, but not nice enough to justify using Gnome 0.6 for all eternity.
Now you're just being silly. Is OS X isolated from outside developments? No. Because the entire system core moves as one large piece. The applications are more dynamic, but they always are targetted directly at a minimum system level. This is different from Linux where Debian Woody can mean different things to different people depending on how many updates they've done from the repository. One system could be GLib 2.1, while another could be GLib 2.5*. An application may then refuse to install either because you don't have a new enough version of GLib, or because your version is too new!
If a system core moves at as all or nothing standard, then this issue doesn't exist. If a program needs an API that isn't included in the core, it can bundle it. The user's life is easier, and the system maintainer's lives are easier.
* Made up version numbers. I don't remember what the real ones are.
Circular dependencies are not a problem - if you view the set of packages and their dependencies as a directed finite graph - it's easy to come up with an algorithm for reliably figuring out the closure of dependency relations for any given package or set of packages.
:-)
Exactly! You're thinking right along the same lines I am. The key is to view the system as a whole, because that is how it will operate. Once the system *is* whole, then many of the circular dependency issues go away. It's only through the concept of componetizing dependent components that we arrive at the issues common to packaging systems. What we really need to work out is how it might be possible to create a distribution system that doesn't exhibit these issues.
My thought is that a system core that can be treated as a whole is half the solution. The other half is discrete applications that don't attempt to upgrade the core, and keep all non-core APIs to themselves. If a particular library starts popping up across several applicaitons, it can then be added to a future version of the OS core.
They also don't have the resources to making security patches for every package without upgrading to a newer version of said package (i.e. backporting). They really do a phenominal job given their constraints.
:-)
I agree wholeheartedly. I'm not attempting to "diss" the Debian distro or its maintainers. I'm only pointing out that the packaging system is beginning to strain under the pressure of so many packages. The complexity of the package system is quickly becoming too difficult to maintain. Especially since the packaging system mixes the core system APIS with the user applications. (Always a recipe for trouble.) Thus it is time to start thinking about something new.
The Linux Standard Base is dead.
The LSB was always about the "least common denominator" and not about "the most usable configuration". For what it was, it wasn't too bad. But a real standard at this point would have to define a lot more libraries, although perhaps at more of a library version level than trying to force the individual APIs.
With that in mind, I don't think that such a standard should be attempted across all distros. For one, that would limit their ability to be different and provide new competitive services. For another, it tends to be better to allow a few different standards to compete before you attempt to pick one or two out of the fold. For example, there used to be many standards for Linus base distros. Now all distros tend to fork from either RedHat or Debian. Standards thus emerged.
The same thing should happen today. We should see different distros attempt differing solutions to the issue and see which ones work best. Symphony is certainly one of the most interesting, but mostly because it's the first attempt to break away from the current designs that Linux is stuck in.
Chief among the problems, he said, were cyclic dependencies and the fact that software installation tool apt depended heavily on the changing C++ libraries.
:-)
Let this be a lesson to those of you who claimed that "APT is unbreakable." There's no such thing as an unbreakable technology. There is however, such a thing as a robust technology that resists failure. As packaging systems go, APT is fairly good. However, my belief is that packaging systems are inherently flawed.
What you want in an OS, is a method for determining the precise core upon which you can base your applications on. Such a core would effectively be an immutable set of system APIs that cannot be changed. The upshot to this situation is that the given system is verifyable. i.e. I can have a script go through and ensure that everything that should exist does exist. From that information, I can then do a delta to find out what exists that shouldn't exist.
This is in direct opposition to a packaging system that builds an OS out of inter-dependent components. The problem with such a strategy is that using inter-dependent components only works if you're building from scratch. As anyone who has managed a version control system can tell you, things get extremely complicated (and tend to require manual intervention) as soon as files start branching. The same thing happens in packaging systems as soon as you start doing upgrades to individual components. Soon you find yourself with a mess of mismatched dependencies which require constant manual intervention to solve. Not a good situation.
In the case of a defined core, you can simply wipe out the old core and replace it with the new one. As long as testing has been done to ensure that the new components are still backward compatible with old software, everything should work fine after the upgrade.
Food for thought, anyway. To the Debian team: Thanks for the new release! Even if there are some growing pains, it's still nice to see you back in the game.
- How do you set a static path to a file, when several have the same name ? Live queries are moving targets. Unique IDs are not enough IMHO.
Node IDs work more than well enough for OS X. They are core to the IOKit, and as a result all programs support them.
- Interoperability between systems become a nightmare
How so? A stream of bytes with a name is still a stream of bytes with a name. The meta data is additional information on top of that.
- How do you manage a trashcan ? More importantly, how do you manage the trashcan without confusing the user ?
Simple, just like today. Trash cans would be a single area full of the files that were deleted. As with most trashcans, the view is flat. All attributes would be restored if the file were restored.
- Most normal users have BIG problems understanding how to make good queries in Google, but all of this suppose they will become proficient at making queries, and I have serious doubts about that
Well, labelling and stored file searching are two methods for accomplishing the same thing. Labelling works a bit like folders do today, while stored queries provide the user with a more free-form method. If you don't feel comfortable with saved queries, don't use them. However, I think you'll find the concept straight forward enough. e.g. Search for "Movies" and you'll get all your movies.
- How do you manage your pile of queries, once you have tens of them ? (I guess you don't, what a horrible mess)
Spotlight allows you to create "Smart Folders". These look like regular folders but are actually saved queries that execute when you access them. In practice, they should be no more messy than a regular set of folders.
- Where do you save a document ? I mean, you save it, you don't know where, but how do you get it back ? For example, you save it with Word 2003. Now you want to use Word 2005, or, say OOo. How do you do that ?
Save it to one of the media options on your computer. Instead of folders on the given media, you should see a list of Labels that you can attach. An unlabeled file will show up in the root folder.