It is somewhat confusing. When a recipe is being created there is no Dependency checking. After the intial compile (of the recipe author) a Resources/Dependencies file is created automatically using some ldd and other tricks. Once the recipe is contributed there is an existing Resources/Dependencies file and it is used.
It sounds like you're more concerned about mount points than anything. Realisticly, you'd what everything installed locally for performance. Drives are cheap and so much faster. But regardless, imagine the following:
/ [root fs]/Mount/NFS-Apps [Apps available via NFS server]/Mount/Local-Apps [Apps on local 2nd partition]
Then it is just a matter of creating symlinks from:/Programs/Foo ==>/Mount/NFS-Apps/Foo or/Programs/Foo/1.0 ==>/Mount/NFS-Apps/Foo/1.0/Programs/Foo/1.2 ==>/Mount/Local-Apps/Foo/1.2
An autoconf recipe can be created with a simple "MakeRecipe http://dl.sf.net/foo/foo-1.0.tar.gz". In many ways creating a Compile recipe is easier than compiling by hand.
That is exactly what GoboLinux does. All files from/Programs/Foo/1.0/[bin|sbin|lib|...] are linked into/System/Links/[Executables|Libraries|...]
The symlinks are managed by a script called SymlinkProgram.
In addition, there are legacy symlinking (/bin,/usr/bin) that point to/System/Links/Executables.
Re:Wow. Out of touch..
on
The GNOME Roadmap
·
· Score: 2, Interesting
It is entirely possible to focus software development efforts into making "the best solution" instead of aimlessly pouring effort into "100 different, equally crappy solutions".
But you're forgeting that each of those 100 different solutions is best for 100+ different types of people. FOSS allows that fragmentation. Commercial software needs to take the "shotgun" approach. Throw a bunch of features and hope some of them hit. FOSS takes the the "sniper" approach. Choose the right caliber bullet and aim for the kill zone. The analogy even carries over to availablity. There are a handful of shotgun gauges available while a large selection of caliber for rifles.
But the difference is in radioactive density (made up term). With coal all that radiation is dumped into the air slowly. With nuclear power, we have a very dense very toxic radioactive waste that we don't know what to do with.
Arguably, coal is the equivalent of making a dirty bomb with that waste and blowing it up in the upper atmosphere.
Don't forget the parity only really began with the G5. If the G5 scales as quickly as the Intel/AMD world then the trickle down to mid and maybe eventually low end will match.
In the end, Apple uses that curve to encourage consumers to buy up, which is good for earnings.
And that just shows how lucky Apple was to choose a Unix base for OS X. They're able to ride the Linux wave, yet remain separate. At some point, X11 with be installed by default and Cocoa will just be another widget set along with QT and GTK+. Apple with be forced to kicking and screaming, but eventual they will. I'm glad they have that option.
I suspect the reason the BSDs have forked is they're complete systems rather than just a kernel. More chances of conflict with with the larger code base. In addition, the two oldest BSD forks came about when 386BSD died. Both had enough interest to survive. That started a mindset and tradition of multiple BSDs. Linux would be different if Linus also created a distribution. Instead he focussed solely kernel. Distributions fork but the kernel doesn't.
My first real experience with free software was with the Amiga. Most of it was Public doamin and the distribution was via Fred Fish discs listed in magazines. Certain authors started making a name for themselves. The commercial market was so small it was hard for the code to be commerialized. A good example was C compilers. (Matt) Dillions Intergrated C Environment or DICE was much better than either of the commercial compilers (Lattice and Aztec). Yeah a lot of PD soft was crap. But look at all the projects on sf or freshmeat. Ratio was about the same.
Perhaps it could be modified to include a link explaining that IE isn't standards compliant and providing a few alternatives. If even only 20% leave the link due to political or lazy/ignorant reasons, imagine the amount of mindshare that could be generated.
Very true. I overclocked the 68000 in my Amiga 500. Reliability was a major problem. Ended up using an ice cube in a ziplock. Not very sustainable but fun (hey I was 12). I'm sure the later Genesis had underclocked CPUs. At the time 68030 and 040s where current in PCs.
Doesn't make a difference if you're running 1 or 5 machines in your house, but it does make a signifigant difference if you're running 500 or machines.
Sorry that just doesn't make sense. Power consumption is proportional to the number of machines. Price is also proportional to the number of machines. Therefore the quantity cancel each other out.
Cooling costs affect the equation somewhat but not enough. Especially compared to the cost of realestate. Increasing computational density (/m3) is much more important. Real estate is expensive in SF Bay!
In addition OS X is very standards oriented. They WANT to interoperate. They also happen to provide many value added features that many people are willing to pay for. I think they have resigned themselves to being a niche player. As Linux grows they can also grow. It is all unix-like anyways. I would not be surprised if they ported Cocoa to Linux someday, just like OpenStep was available on Windows.
Not as cool but Best Buy has 400 disc DVD changes for $400. Three of those and you're set. Cheap and out of the box. If you want to get fancy, feed them into video capture and stream across the network.
I assume you're refering to Earth Final Conflict. I rather liked the show, but it was impossible to watch sequentially, The syndication schedule seems random, and that was with a season pass on Tivo!!! That's where the show failed.
It is just a matter of how well we support it. Currently, nothing. The result, we end up using windows drivers. Examples are ndis and ntfs.sys. This trend will continue.
An alternative, come up with a standard API for each device type (video, ethernet, scsi, etc) Then create a wrapper between the internal API and the spec. Internal API changes, port the wrapper. If we can do it with windows drivers we should be able to come up with something more efficient and less hackish.
Original API aged poorly? Design a new one and implement the wrapper as another driver. Both can coexist.
I see no reason Linus would have a problem with this from a tech perspective. It's just another driver. GPL drivers could avoid the wrapper and would remain prefered.
Parallel implementation with a BSD would avoid most of the licensing issues.
Is MythTV network capable? Can I have a monster recording server and then playback clients on my LAN? Can I rip a DVD/CD at the client and store it on the server? What about DVD burning. I'm about to purchase the Pioneer Tivo DVD burner. Cost wise this could actually be worthwhile.
But think about it. IBM is learning from its mistakes. Sometime Pre-1980 IBM decided they didn't want to maintain an OS for a volume play. The result, IBM PC and Microsoft. The PC became an ocean of clones and Bill Gates, Neptune. IBM retreated into the highend. Now, the clones are approaching the highend.
Now, IBM is aligning itself with a free os hoping to eliminate that type of market domination. Meanwhile, IBM Global Services, can make a fortune in consulting fees, and eliminating R/D for OS on their highend.
Slashdot Mirror
Gnome 2 should have shipped with an optional "power user control centre" type app that provided the tweakability users now miss.
That is a great idea. Of course it would be TOO similar to TweakUI. Can't go copying MS again can we.
It is somewhat confusing. When a recipe is being created there is no Dependency checking. After the intial compile (of the recipe author) a Resources/Dependencies file is created automatically using some ldd and other tricks. Once the recipe is contributed there is an existing Resources/Dependencies file and it is used.
Does that help?
It sounds like you're more concerned about mount points than anything. Realisticly, you'd what everything installed locally for performance. Drives are cheap and so much faster. But regardless, imagine the following:
/Mount/NFS-Apps [Apps available via NFS server] /Mount/Local-Apps [Apps on local 2nd partition]
/Programs/Foo ==> /Mount/NFS-Apps/Foo /Programs/Foo/1.0 ==> /Mount/NFS-Apps/Foo/1.0 /Programs/Foo/1.2 ==> /Mount/Local-Apps/Foo/1.2
/ [root fs]
Then it is just a matter of creating symlinks from:
or
An autoconf recipe can be created with a simple "MakeRecipe http://dl.sf.net/foo/foo-1.0.tar.gz". In many ways creating a Compile recipe is easier than compiling by hand.
That is exactly what GoboLinux does. All files from /Programs/Foo/1.0/[bin|sbin|lib|...] are linked into /System/Links/[Executables|Libraries|...]
.
/usr/bin) that point to /System/Links/Executables.
The symlinks are managed by a script called SymlinkProgram
In addition, there are legacy symlinking (/bin,
It is entirely possible to focus software development efforts into making "the best solution" instead of aimlessly pouring effort into "100 different, equally crappy solutions".
But you're forgeting that each of those 100 different solutions is best for 100+ different types of people. FOSS allows that fragmentation. Commercial software needs to take the "shotgun" approach. Throw a bunch of features and hope some of them hit. FOSS takes the the "sniper" approach. Choose the right caliber bullet and aim for the kill zone. The analogy even carries over to availablity. There are a handful of shotgun gauges available while a large selection of caliber for rifles.
Wow, I'm sounding like ESR now.
I took CS354 with Goodman back in 92. Very good class and teaching tool.
But the difference is in radioactive density (made up term). With coal all that radiation is dumped into the air slowly. With nuclear power, we have a very dense very toxic radioactive waste that we don't know what to do with.
Arguably, coal is the equivalent of making a dirty bomb with that waste and blowing it up in the upper atmosphere.
Don't forget the parity only really began with the G5. If the G5 scales as quickly as the Intel/AMD world then the trickle down to mid and maybe eventually low end will match.
In the end, Apple uses that curve to encourage consumers to buy up, which is good for earnings.
And that just shows how lucky Apple was to choose a Unix base for OS X. They're able to ride the Linux wave, yet remain separate. At some point, X11 with be installed by default and Cocoa will just be another widget set along with QT and GTK+. Apple with be forced to kicking and screaming, but eventual they will. I'm glad they have that option.
I suspect the reason the BSDs have forked is they're complete systems rather than just a kernel. More chances of conflict with with the larger code base. In addition, the two oldest BSD forks came about when 386BSD died. Both had enough interest to survive. That started a mindset and tradition of multiple BSDs. Linux would be different if Linus also created a distribution. Instead he focussed solely kernel. Distributions fork but the kernel doesn't.
My first real experience with free software was with the Amiga. Most of it was Public doamin and the distribution was via Fred Fish discs listed in magazines. Certain authors started making a name for themselves. The commercial market was so small it was hard for the code to be commerialized. A good example was C compilers. (Matt) Dillions Intergrated C Environment or DICE was much better than either of the commercial compilers (Lattice and Aztec). Yeah a lot of PD soft was crap. But look at all the projects on sf or freshmeat. Ratio was about the same.
Perhaps it could be modified to include a link explaining that IE isn't standards compliant and providing a few alternatives. If even only 20% leave the link due to political or lazy/ignorant reasons, imagine the amount of mindshare that could be generated.
Very true. I overclocked the 68000 in my Amiga 500. Reliability was a major problem. Ended up using an ice cube in a ziplock. Not very sustainable but fun (hey I was 12). I'm sure the later Genesis had underclocked CPUs. At the time 68030 and 040s where current in PCs.
Sorry that just doesn't make sense. Power consumption is proportional to the number of machines. Price is also proportional to the number of machines. Therefore the quantity cancel each other out.
Cooling costs affect the equation somewhat but not enough. Especially compared to the cost of realestate. Increasing computational density (/m3) is much more important. Real estate is expensive in SF Bay!
In addition OS X is very standards oriented. They WANT to interoperate. They also happen to provide many value added features that many people are willing to pay for. I think they have resigned themselves to being a niche player. As Linux grows they can also grow. It is all unix-like anyways. I would not be surprised if they ported Cocoa to Linux someday, just like OpenStep was available on Windows.
Not as cool but Best Buy has 400 disc DVD changes for $400. Three of those and you're set. Cheap and out of the box. If you want to get fancy, feed them into video capture and stream across the network.
Forgot one.
0. A robot may allow harm to a human being for the benefit of the species.
Or something like that. Forget which book it was revealed in.
I assume you're refering to Earth Final Conflict. I rather liked the show, but it was impossible to watch sequentially, The syndication schedule seems random, and that was with a season pass on Tivo!!! That's where the show failed.
It is just a matter of how well we support it. Currently, nothing. The result, we end up using windows drivers. Examples are ndis and ntfs.sys. This trend will continue.
An alternative, come up with a standard API for each device type (video, ethernet, scsi, etc) Then create a wrapper between the internal API and the spec. Internal API changes, port the wrapper. If we can do it with windows drivers we should be able to come up with something more efficient and less hackish.
Original API aged poorly? Design a new one and implement the wrapper as another driver. Both can coexist.
I see no reason Linus would have a problem with this from a tech perspective. It's just another driver. GPL drivers could avoid the wrapper and would remain prefered.
Parallel implementation with a BSD would avoid most of the licensing issues.
Are any of these for nextel?
The kitcar market is actually pretty large. Plenty of ferrari kits for Fieros and Hummer for trucks.
There is also a very large kitplane industry. Everything from plans to every part for biplanes to jets.
Have you tried Mac-on-Linux?
Is MythTV network capable? Can I have a monster recording server and then playback clients on my LAN? Can I rip a DVD/CD at the client and store it on the server? What about DVD burning. I'm about to purchase the Pioneer Tivo DVD burner. Cost wise this could actually be worthwhile.
But think about it. IBM is learning from its mistakes. Sometime Pre-1980 IBM decided they didn't want to maintain an OS for a volume play. The result, IBM PC and Microsoft. The PC became an ocean of clones and Bill Gates, Neptune. IBM retreated into the highend. Now, the clones are approaching the highend.
Now, IBM is aligning itself with a free os hoping to eliminate that type of market domination. Meanwhile, IBM Global Services, can make a fortune in consulting fees, and eliminating R/D for OS on their highend.