So, can I go to a website and click on a link and download a new package and have it just install by opening it? Can this package open a GUI to allow options to be chosen (things like optional features, like spell check and file associations)? Welcome to Mac OSX, which runs on glorious appdirs that make software installation almost trivial for everything except daemons.
Lots of people run Linux on the MBP. I, personally, was too scared of screwing up my EFI and boot records to run Boot Camp without Windoze (besides, it demanded 347MB to install! BLOATWARE!), so I looked at virtualization options. Being too cheap to pay for VMWare Fusion or Parallels, I eventually opted for the free, dual-licensed VirtualBox.
So now I can use OSX applications with a Gentoo machine compiling code in the background, with no human-noticeable slowdown (though I did have to find and turn on the option to use Intel's virtualization processor feature thingy).
I run a virtualized Linux machine more powerful than my old desktop for development purposes while reading Slashdot on a wireless network that works perfectly and seamlessly without any tinkering on my part. Oh, and the virtualizer gives Linux an ethernet card that simply routes packets through OSX, so I don't have to configure that either.
Hell, last night I was running "emerge --update world" on Linux while reading webcomics. I can use my nearly-a-week-old Macbook Pro to run "normal" things as easily as I could want while running a Linux environment to tinker with when I want to and only when I want to.
Actually, Boot Camp and virtualization software work best for users who want Linux functionality. My virtual Linux box on a Macbook Pro runs faster and better than my actual Linux desktop!
Have you taken a look at Scsh? I, personally, would like to see AREXX/AppleScript-like application scripting abilities added to something like that so it could drive GUI apps as well as command-line ones. Then I'd pretty much consider it perfect.
No, I mean a replacement for the antiquated Unix build system of M4 (the macro language I spoke of), autoconf, automake, and make itself. Once you look into how one actually uses them, they basically only support Fortran and the various dialects of C. Other languages have to supply their own tools for generating makefiles, and then of course makefiles themselves are now so inhumanly complicated that few can manipulate them without some kind of automated tool any longer.
I'd like a build system that:
1) Programmers can comprehend and use as an incidental tool without starting a "learn autotools" project at work. 2) Supports both compilation of source files and the installation of interpreted files. 3) Part and parcel with #2, supports any language I can supply a compiler or interpreter for.
Note that build systems perform separate functions and solve separate problems from package managers. I have fond memories of working under Delphi 5 Standard: I'd activate a menu selection (maybe by its hotkey) and have my entire project update itself or even fully rebuild itself. I understand that not everyone should have a copy of my IDE, but I'd like to think that we can make the building of distributed source code that easy and language-transparent. It would save application developers a lot of hassle.
I mostly agree with you, but you should face that we will never, ever run systems powered entirely by one language. Different languages solve different problems, and binary (+ interpreters that were themselves compiled to binary) provides enough of a common platform for most applications.
On the other hand, the use of a single high-level language (like bash, AREXX, or AppleScript) to tie multiple applications and their functionality together would be very nice.
Or better yet, why not take the open-source base of OSX (say... OpenDarwin and the BSD userland) and write a full suite of F/OSS workalike software to replace Apple's non-free bits?
If you wanted it to run on Linux, you could port the thing to a GNU userland and... say... MkLinux or L4Linux.
APPDIRS! APPDIRS! APPDIRS! Also known as "bundles" under OSX, they are the closest I've ever seen anything come to an ideal packaging solution. You have directories for programs sorted by category:/Applications,/Libraries,/Daemons, etc., and each "bundle" is a directory in one of those hierarchies with a name like (gasp at the sheer simplicity) "bash-3.1" (you can add a symlink called bash if you want, too). That bundle/appdir contains every system-wide file owned by the package, just like under Windoze. User-specific configuration files go somewhere in users' home directories, just like under Linux.
To install software, put its bundle in the appropriate hierarchy. To uninstall software, remove a bundle and remove personal settings.
Admittedly, tools like apt or emerge that can read and display package repositories, build custom packages (ports and portage), or resolve dependencies still have great use, but in an appdir system they rest upon a much simpler, more solid foundation.
Linux multimedia dev, meet Simple Direct-media Layer. It's been done, it's used, it works, and it's open. The trouble lies in the politics of getting developers to port their games and engines over to SDL from DirectX and other proprietary libraries.
I'm going to quote my design text file for the whole "replace X" thing:
An improved windowing system will not function as the foundation of graphics fun ctionality. It will run on top of that foundation. For example, it might run o n top of an SDL implementation that runs without a windowing system under it.
I can temporarily call it the Fork Window System.
Fork runs as a daemon that accepts connections from threads. Applications conne ct by sending ForkWS a display program they wish interpreted/run (written in a l anguage like say... PostScript or something). Fork then forks off a thread that
interprets the display program, drawing the desired window. Connections go onl y two ways, between one display thread and one application thread. Display prog rams can perform two functions: actually draw in their window and function as wi ndow mnagers for sub-windows created using space in their window. Display progr ams for sub-windows run in their own threads.
When a display program wants to send data to or receive data from the driving ap plication thread, then they can invoke an IPC interface of some sort, probably s ynchronous message passing. However, ForkWS itself will asynchronously queue in put (and possibly output) events to be fed to specific display threads when aske d.
The design pretty much forces programs into a parallelism model of one UI thread
communicating with at least one driver application thread, which itself may communicate with several worker threads. Look up "NeWS" on Wikipedia to see my inspiration. A better windowing system was invented, but it lost out because it wasn't an open standard (and was therefore both more expensive to use and more expensive to develop for).
Someday Apple's lockin may very well go as far as M$'s. But people will still buy Apple machines on that day because, unlike Windoze, OSX actually works extremely well on its target market of machines and supports the features people want.
History shows that people will support a regime that takes away all their freedom but gives them what they otherwise want.
Disclaimer: I run OSX with a virtualized Linux machine for development.
Moreover, Microsoft and Apple (really mostly Apple, but M$ has done it) can break compatibility when they want to. Quartz and Aqua honestly provide my Mac with a better user experience than I've ever had or even seen under Linux (including: Red Hat, Mandrake, Linux From Scratch compiled with KDE, Gentoo with KDE and then Fluxbox, Ubuntu and Kubuntu), but the insistence in the Linux/FOSS community on using nothing but "open standards" and Unix technology mean that nobody has started writing anything comparable to Quartz for pure *nix, even though most Linux/Solaris workstations, desktops and laptops now include the necessary hardware power.
While we're at it, how about a configuration and build system that doesn't require me to learn a medium-sized macro language just to distribute a package that will compile and run on other people's machines? Maybe we can be really nice to ourselves and even invent such a system that doesn't care what language I coded in!
You just switched from Linux PC -> Macbook Pro too, huh? Check out VirtualBox an x86 virtualization app that seems to support enough to run a Linux spare-desktop or development environment (meaning no heavy multimedia) under OSX with very good performance. It comes in a closed-source edition that allows a personal/educational use freeware license and an open-source edition.
In case you wondered, yes: after getting a Macbook Pro I didn't want the hassle of running Linux on top of BootCamp (since BootCamp was designed explicitly for Windoze, damnit), and I was too cheap to shell out $80 for Parallels or VMWare Fusion. Also, I wanted to leave an open-source option open should licensing become too restrictive for me.
And the real best reason to use Gentoo is integration. When everything compiles on your machine, from source, it always knows exactly where everything else is and never goes looking for anything that doesn't exist.
For example, I could never get KVPNC working on an Ubuntu laptop I used for work. After I compiled KVPNC from source, it worked perfectly. Hmmmm....
Just noting, but Intel does very little in the United States any longer. Most of their manufacturing has gone to China, while their engineering went primarily to India and Israel.
Right. That is why scores of Jews lived unmolested all over the Middle East prior to Israel appearing on the scene, significant numbers still remaining, in places like Iran. You mean as second-class citizens? I recommend checking into the history of those Persian Jews. The only ones remaining in Iran are the hard-core Haredim who believe we must wait for the Messiah to establish a state of our own. All the rest have, voluntarily or otherwise, made aliyah into Israel.
Ain't the Zionist Exceptionalism and Supremacism grand? Those damn Neandearhal Arabs, who lived in mud huts and ate dirt and little pebbles, exchanging unintelligible grunts, until the Enlightened, Glorious, Inteligent Zionists on a Mission From God arrived with cartloads of Money to bring Civilization to the poor wretches... and a bit of administrative "resettlement" along with it. Apparently you've never heard of the Ottomman Empire. The Turks officially owned the land that the Arabs worked. When the Jews brought money into the area, the Arabs saw a possible improvement to their near-feudal existence.
... and of which the dirt-eating Arabs were not consulted, nor whose approval of the plan was deemed even remotely necessary, them being pebble-collecting swamp dwellers... and which, surprise, shock, horror, they "rejected"! And only because it made most of them into either Zionist subjects or into peoples disposessed -- So how dare they! And over such a small "trifle" too! Ungrateful savages! So the Arabs don't have to listen to UN plans on which they weren't consulted? Great, neither does Israel.
The Zionists do no Jew any favours by trying to conflate Jewry with Zionism. It is one thing to unjsutly persecute Jews for mere membership in their religion, quite another to resist the supremacist machinations of Zionists. Of course your attempt to tie the two together into an inseparable knot makes your true stripes show through quite clearly. Your use of flame to hide the fact that you didn't even look my concepts up on Wikipedia really shows.
Yes, the relevant "cultural" background is that of a bunch ex-Europeans who arrived to kick the shit out of a bunch of locals in order to confiscate their land and lord over the disposessed, on an apparent mission of Manifest Destiny pre-ordained by their God who, according to them, designated the area in question as "theirs". The other side responded in kind, by attempting to get rid of the belligerent conquerors via any-and-all violent means, from all-out military conflict involving tanks and airplanes, to, as the desperation grew, all the way to strapping bombs to their asses and blowing themselves up. So you're one of those idiots who believes that Jews don't originally come from the Middle East? Or do you believe that the most recent majority population properly owns the land? If the former, you're delusional. If the latter, the Israelis now own Israel and the settlers can acquire whatever they want through high breeding rates.
Or you can start believing something that makes sense.
Incidently, since the Israeli Arabs have such a high birth rate, the Zionists fear that their numbers will soon reach proportions which will threaten the "Jewish" nature of the state of Israel, and are busy concocting ever more Appartheid-like counter-measures, restricting the Arab's abilities to vote or organize politically. Loud and serious talk about forced, religiously and racially motivated deportations abounds amongst Likudniks. Sober analysis has generally shown the "demographic bomb" to be a hack political strategy. As the lives and welfare of the Israeli Arabs improves, they actually breed less. And that welfare is why few will give up their Israeli citizenship for Palestinian citizenship.
Slashdot Mirror
Wasting your time, or paying you to surf the web?
Lots of people run Linux on the MBP. I, personally, was too scared of screwing up my EFI and boot records to run Boot Camp without Windoze (besides, it demanded 347MB to install! BLOATWARE!), so I looked at virtualization options. Being too cheap to pay for VMWare Fusion or Parallels, I eventually opted for the free, dual-licensed VirtualBox.
So now I can use OSX applications with a Gentoo machine compiling code in the background, with no human-noticeable slowdown (though I did have to find and turn on the option to use Intel's virtualization processor feature thingy).
Yeah, because nobody ever dumps Linux for an OSX machine they'll never have to tinker with just to make it work.
I run a virtualized Linux machine more powerful than my old desktop for development purposes while reading Slashdot on a wireless network that works perfectly and seamlessly without any tinkering on my part. Oh, and the virtualizer gives Linux an ethernet card that simply routes packets through OSX, so I don't have to configure that either.
Hell, last night I was running "emerge --update world" on Linux while reading webcomics. I can use my nearly-a-week-old Macbook Pro to run "normal" things as easily as I could want while running a Linux environment to tinker with when I want to and only when I want to.
Actually, Boot Camp and virtualization software work best for users who want Linux functionality. My virtual Linux box on a Macbook Pro runs faster and better than my actual Linux desktop!
Have you taken a look at Scsh? I, personally, would like to see AREXX/AppleScript-like application scripting abilities added to something like that so it could drive GUI apps as well as command-line ones. Then I'd pretty much consider it perfect.
No, I mean a replacement for the antiquated Unix build system of M4 (the macro language I spoke of), autoconf, automake, and make itself. Once you look into how one actually uses them, they basically only support Fortran and the various dialects of C. Other languages have to supply their own tools for generating makefiles, and then of course makefiles themselves are now so inhumanly complicated that few can manipulate them without some kind of automated tool any longer.
I'd like a build system that:
1) Programmers can comprehend and use as an incidental tool without starting a "learn autotools" project at work.
2) Supports both compilation of source files and the installation of interpreted files.
3) Part and parcel with #2, supports any language I can supply a compiler or interpreter for.
Note that build systems perform separate functions and solve separate problems from package managers. I have fond memories of working under Delphi 5 Standard: I'd activate a menu selection (maybe by its hotkey) and have my entire project update itself or even fully rebuild itself. I understand that not everyone should have a copy of my IDE, but I'd like to think that we can make the building of distributed source code that easy and language-transparent. It would save application developers a lot of hassle.
I mostly agree with you, but you should face that we will never, ever run systems powered entirely by one language. Different languages solve different problems, and binary (+ interpreters that were themselves compiled to binary) provides enough of a common platform for most applications.
On the other hand, the use of a single high-level language (like bash, AREXX, or AppleScript) to tie multiple applications and their functionality together would be very nice.
Or better yet, why not take the open-source base of OSX (say... OpenDarwin and the BSD userland) and write a full suite of F/OSS workalike software to replace Apple's non-free bits?
If you wanted it to run on Linux, you could port the thing to a GNU userland and... say... MkLinux or L4Linux.
I know it's been said elsewhere but...
/Applications, /Libraries, /Daemons, etc., and each "bundle" is a directory in one of those hierarchies with a name like (gasp at the sheer simplicity) "bash-3.1" (you can add a symlink called bash if you want, too). That bundle/appdir contains every system-wide file owned by the package, just like under Windoze. User-specific configuration files go somewhere in users' home directories, just like under Linux.
APPDIRS! APPDIRS! APPDIRS! Also known as "bundles" under OSX, they are the closest I've ever seen anything come to an ideal packaging solution. You have directories for programs sorted by category:
To install software, put its bundle in the appropriate hierarchy. To uninstall software, remove a bundle and remove personal settings.
Admittedly, tools like apt or emerge that can read and display package repositories, build custom packages (ports and portage), or resolve dependencies still have great use, but in an appdir system they rest upon a much simpler, more solid foundation.
Somehow I think that Darwin and OpenDarwin serve better as viable microkernel operating systems, since people actually use them and everything.
Linux multimedia dev, meet Simple Direct-media Layer. It's been done, it's used, it works, and it's open. The trouble lies in the politics of getting developers to port their games and engines over to SDL from DirectX and other proprietary libraries.
Scripting for GUI applications shouldn't actually be too hard. Amiga's AREXX did it twenty years ago, and AppleScript does it today.
ctionality. It will run on top of that foundation. For example, it might run o
n top of an SDL implementation that runs without a windowing system under it.
I can temporarily call it the Fork Window System.
Fork runs as a daemon that accepts connections from threads. Applications conne
ct by sending ForkWS a display program they wish interpreted/run (written in a l
anguage like say... PostScript or something). Fork then forks off a thread that
interprets the display program, drawing the desired window. Connections go onl
y two ways, between one display thread and one application thread. Display prog
rams can perform two functions: actually draw in their window and function as wi
ndow mnagers for sub-windows created using space in their window. Display progr
ams for sub-windows run in their own threads.
When a display program wants to send data to or receive data from the driving ap
plication thread, then they can invoke an IPC interface of some sort, probably s
ynchronous message passing. However, ForkWS itself will asynchronously queue in
put (and possibly output) events to be fed to specific display threads when aske
d.
The design pretty much forces programs into a parallelism model of one UI thread
communicating with at least one driver application thread, which itself may communicate with several worker threads. Look up "NeWS" on Wikipedia to see my inspiration. A better windowing system was invented, but it lost out because it wasn't an open standard (and was therefore both more expensive to use and more expensive to develop for).
Someday Apple's lockin may very well go as far as M$'s. But people will still buy Apple machines on that day because, unlike Windoze, OSX actually works extremely well on its target market of machines and supports the features people want.
History shows that people will support a regime that takes away all their freedom but gives them what they otherwise want.
Disclaimer: I run OSX with a virtualized Linux machine for development.
Moreover, Microsoft and Apple (really mostly Apple, but M$ has done it) can break compatibility when they want to. Quartz and Aqua honestly provide my Mac with a better user experience than I've ever had or even seen under Linux (including: Red Hat, Mandrake, Linux From Scratch compiled with KDE, Gentoo with KDE and then Fluxbox, Ubuntu and Kubuntu), but the insistence in the Linux/FOSS community on using nothing but "open standards" and Unix technology mean that nobody has started writing anything comparable to Quartz for pure *nix, even though most Linux/Solaris workstations, desktops and laptops now include the necessary hardware power.
I dunno. Things like scheduler design, the VFS layer, and I/O latency do affect user experience.
While we're at it, how about a configuration and build system that doesn't require me to learn a medium-sized macro language just to distribute a package that will compile and run on other people's machines? Maybe we can be really nice to ourselves and even invent such a system that doesn't care what language I coded in!
You just switched from Linux PC -> Macbook Pro too, huh? Check out VirtualBox an x86 virtualization app that seems to support enough to run a Linux spare-desktop or development environment (meaning no heavy multimedia) under OSX with very good performance. It comes in a closed-source edition that allows a personal/educational use freeware license and an open-source edition.
In case you wondered, yes: after getting a Macbook Pro I didn't want the hassle of running Linux on top of BootCamp (since BootCamp was designed explicitly for Windoze, damnit), and I was too cheap to shell out $80 for Parallels or VMWare Fusion. Also, I wanted to leave an open-source option open should licensing become too restrictive for me.
Doom, mostly. Doom is nice.
And the real best reason to use Gentoo is integration. When everything compiles on your machine, from source, it always knows exactly where everything else is and never goes looking for anything that doesn't exist.
For example, I could never get KVPNC working on an Ubuntu laptop I used for work. After I compiled KVPNC from source, it worked perfectly. Hmmmm....
Just noting, but Intel does very little in the United States any longer. Most of their manufacturing has gone to China, while their engineering went primarily to India and Israel.
... and of which the dirt-eating Arabs were not consulted, nor whose approval of the plan was deemed even remotely necessary, them being pebble-collecting swamp dwellersOr you can start believing something that makes sense. Incidently, since the Israeli Arabs have such a high birth rate, the Zionists fear that their numbers will soon reach proportions which will threaten the "Jewish" nature of the state of Israel, and are busy concocting ever more Appartheid-like counter-measures, restricting the Arab's abilities to vote or organize politically. Loud and serious talk about forced, religiously and racially motivated deportations abounds amongst Likudniks. Sober analysis has generally shown the "demographic bomb" to be a hack political strategy. As the lives and welfare of the Israeli Arabs improves, they actually breed less. And that welfare is why few will give up their Israeli citizenship for Palestinian citizenship.
Funny old world, ain't it?
Says Anonymous Coward on Slashdot.