I can't imagine a reasonable way to use Gmail style labels in an office environment. I'd hat to have to sort through 600 possible labels to select the right one from a drop down list.
Here's a thought: Don't use a dropdown list. Are dropdowns used to select folders today? No, a directory list is. Make it a label list, and you're gold.
And where are these labels stored anyway? On the server?
Where are folders stored anyway?
What happens when a user upgrades machines? Has to use another computer? Has to tell another employee how to find the group of files she carefully constructed?
What happens to your file system when you upgrade a machine? When you have to use another computer? Has to tell another employee how to find the group of files under labels she carefully constructed?
How does one do a reasonable data only backup in such a mess?
How does one do a reasonable backup of the mess we call hard drives?
I'm sorry, but this notion is destructive in a business environment. It's designed to make users lazy and sloppy about where they keep their data.
I'm sorry, but the only thing lazy and sloppy is your attention. What is a folder? An INode with files linked to it. What is a Label? A unique file system identity with files linked to it. What's the difference? A label can be linked to documents that other labels are linked to. Did you even catch the part about Links == Psuedo-Label functionality to cover the missing holes?
I don't understand why you're so hostile here. There's nothing new except a bit more functionality that makes things work better. Files without labels are nothing more than files stored in a root folder. (Also analogous to Google's All Email.) And separate storage devices are separate storage devices, are separate storage devices. You don't complain that mapped drives "make a huge mess that is impossible to manage" do you? So don't act like a dope about this.
Re:PHP definitely does not follow the KISS princip
on
A Decade of PHP
·
· Score: 1
Before I speak, allow me to point out that I've worked with ColdFusion for several years myself. So I know what I'm talking about when I say IT SUCKS!
The purpose of languages like Java (and by extension JSP) is to prevent programmers from making really stupid mistakes that make sites unusable. ColdFusion has NO protection against stupidity, and will happily blow up in the tinest of situations. Especially when its coupled with Stored Procedures (the 'Standard').
And yes, I'm leveling these accusations against CFMX as well. CF is just painful to work with, and creates many more problems for the programmer and users than it should.
You know, after you and others mentioned this, I dug into smart folders to figure out if they are the same. It doesn't appear to me that they are. In a Label type system, the Label shows up as if it were a folder. (See the GMail interface for an example.) The Label is precreated and unique, so you stamp it on files instead of having the info stored in multiple files. A bit like SQL keys.
If I understand Smart Folders, they only group based on a search of existing Meta-Data. It doesn't sound like there's any way to pretend like you're adding a file to a psuedo-folder. If that's the case, then Smart Folders is still a broken metaphor that needs to be expanded.
Now, let's take this into the work place, where you have 300 users and a central server. How do the users know they're working off the "official" version of the file from the server?
They should show up as different devices. i.e. I have a repository over here on the server, and over here on the desktop. This is pretty straightforward on OS X. More complex solutions in the future (which would pose some issues) could allow administrators to force all user files onto the network, then keep a "cache" of the files on the local machine for travelling laptops. (Windows has a similar feature now.)
What happens when a user makes a typo when entering meta data for associating files with a project?
Not a GMail user I assume? Look, Labels work just like folders. You create it, it looks like a folder, walks like a folder, talks like a folder, and quacks like a folder. Therefore it's a duck^H^H I mean... Folder. The primary difference between the Label and Folder is that you can have documents under multiple Labels. Links, as we use them today, are just a workaround to make up for this missing metaphor.
This is just more of Apple introducing ideas that will make actual work more difficult in the interest of letting increasingly stupid users write letters, pirate MP3s and surf for porn.
I can only assume that you've never actually USED an Apple. Because I get far more work done on my Apple than I ever do on my PC. Or perhaps you'd like to explain how ubiquitous spell checkers, applications as a file, built-in Java, files getting saved properly even if moved, automatic file associations, Expose, and a billion other USEFUL features for getting work done are only targetted at Pirates and Pr0n lovers?
It's easier than you think, actually. When it comes down to it, the primary difference a user will see between a Folder and a Label is that Folders can only hold a file once, while Labels can hold the same file multiple times. i.e. The concept just pushes existing abstractions just a bit farther.
File links have always been a sort of "hack" to get around that fact that files can only be in one folder at any given time. With a database file system, you can keep the one folder per file metaphor, or you can grow into the folders as metadata concept. Your choice.
The greatest danger in Desktop metaphors has always been that the metaphor will be taken to its fully restrictive extreme, and that the powers added by the computer will be ignored. That's exactly what's happened in this case, and it's not a good thing.
Maybe I should blog something more complete about this...
Thanks. I misunderstood what Smart Folders were. This just further underscores that Apple is the only company willing to take risks to offer useful features to their customers. I'm not quite sure what makes Wired think that Finder and Smart Folders are somehow diametric. The two are actually perfectly matched. Finder allows you to browser all the folders on your system. It's good at that. If the folders just happen to be saved queries, who really cares? The interface still works. It's just boggles my mind that no other OS has latched onto this concept before now, despite the overwhelming evidence that it's A Good Idea(TM).
Now that Apple's shown everyone the way with database filesystems, I wonder if we could get them to replace the "Recent" menu with "Piles" of recent folders. Wait, they're already looking at that. God, I love this new Apple. (i.e. NeXT renamed.) And that's coming from a guy who's hated Apple his entire life!
There's an interesting article on Wired about the interface changes in Tiger being a precursor to the demise of the classic folder-browsing Finder.
Call me when Folders become saved queries, and then we'll talk about the semi-demise of Finder. Actually, Finder wouldn't leave us at all. In a properly designed database file system, folders/directories should be replaced with standard queries. An example of this is the Labelling system in GMail. You can add a meta-data label to any email, which will then cause that email to appear in a virtual folder of the same name as the label. But if you pay attention to the search bar, you find that the folder is nothing more than a stored search on a key piece of meta-data.
This concept has massive implications for File System Usability. Under the folders-as-search concept, the same files can be organized under multiple folder groupings. This labelling data not only assists users in doing future searches for their information (i.e. A real reason to fill out meta-data other than "It might be useful."), but it also provides the user with a way of organizing ALL data for a given project under one folder without forcing the user to make a copy. It may not seem all that revolutionary, but I think you'll find that a lot of GMail users have already grasped the real power of the concept.
That being said, WHAT'S TAKING SO DAMN LONG?! This stuff was figured out 10+ years ago, and pieces of it were even included in BeOS. NTFS has had many of the necessary features since its inception (just turned off for some bloody reason), and ReiserFS is bringing the same design to Linux. So what is everyone waiting for? The next guy to scoop you on it?
*sigh* Dear Mr. Jobs: Will you please demonstrate to everyone how you do this properly with a file system? Thanks. Kudos to your NeXT development team who's made this possible.
I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets.
The answer is: Two completely different markets.
JSP requires a minimum investment in hardware, resources, and server capabilities that PHP does not. JSP also tends to require more backend APIs than PHP, because you try to keep as much out of the JSP as possible. As a result, JSP tends to be the best solution for Mid to Enterprise class systems, while PHP makes a good choice for Personal to Small Business uses.
Does that answer your question?
Re:Congratulations are in order!
on
A Decade of PHP
·
· Score: 2, Informative
You can easily code your SQL to be database specific if you need it that way, but that shouldn't in any way stop developers from using a generic DB access API. A DB abstraction is nothing more than a mapping of functions, so there's rarely any performance hits. Which means that applications that don't need a specific database (e.g. PHPBB anyone?) could be portable out of the gate. And even if their SQL isn't portable, that's a far easier thing to fix than attempting to add a DB abstraction after the fact.
Re:PHP definitely does not follow the KISS princip
on
A Decade of PHP
·
· Score: 1
Are you smoking crack? PHP is more inconsistent than any other language I've encountered.
Nope, I'm just a realist. PHP was designed to be a web scripting language that wrapped Unix APIs. Nothing more, nothing less. I in no way agree with the fanaticism surrounding PHP (it doesn't make a good general purpose language people!), but it does what it was designed for in a straightforward, simplistic fashion. I usually prefer to do things in JSP/Java, but if it's not an option for some reason then I prefer to use PHP over any other option. Especially over ColdFusion.
In the past two days, I have run across two separate CFM sites that crashed nonstop on simple operations. On one site, the exact same data entry would crash the first few times, then mystically work correctly. I know that a lot of people like CFM for its "simplicity", but it just doesn't cut the mustard for robust and reliable web code.
Re:Congratulations are in order!
on
A Decade of PHP
·
· Score: 3, Interesting
I completely agree. The primary reason why native code would be nice is that a bundled API would help put peer pressure on coders to use it. Which means that we'd see fewer "quick hacks/prototypes" (that always turn into production sites) using database specific code.
Re:Congratulations are in order!
on
A Decade of PHP
·
· Score: 4, Insightful
You wrote an OGG Vorbis decoder in PHP? Maybe I'm missing something, but why? That doesn't strike me as a very good language to be doing such a thing in. The "PHP Way" is to leave heavy processing like that to an external library such as libogg/libvorbis. You can then use PHP as a frontend for presenting info, streaming the data, and uploading files.
I realize that PHP can be cool at times, but one has to use the right tool for the job at hand.:-)
Re:Congratulations are in order!
on
A Decade of PHP
·
· Score: 5, Informative
Dude, you need to provide links. I had to *gasp* Google it!;-)
Looking over the DB classes, it looks like they provide a fairly decent abstraction. Thanks Quinto, that will definitely be nice for future PHP projects.:-)
Probably a troll, but just in case anyone else doesn't know: PHP is a scripting language designed for generating dynamically created web pages. It functions by mixing its scripting in with the HTML, thus allowing programmers to reuse existing page designs. The scripting APIs are centered around those commonly used on Unix systems. PHP is usually bundled with Apache, so no installation tends to be required.
Congratulations are in order!
on
A Decade of PHP
·
· Score: 3, Insightful
Congrats to the PHP development team! PHP has long followed the KISS principle while still maintaining the Unix APIs that we've all learned to know and love. While it's not the best web scripting platform for all purposes, it is a free and flexible alternative for many, many dynamic webpage projects. It's only because of PHP that so many OSS web applications have been allowed to exist.
It was slow to catch and a lot of people didn't get it.
Ok, I'm with the slow-to-catch-on part, but what's this about people not getting it? The concept had to be one of the simplest ever designed. (Thus the reason why it's so common across web scripting languages.) Here is your HTML, here's a bit of Unix scripting langauge. Simple, see?:-)
On a slightly different topic, one wishlist item that I would like to see in PHP is Abstract Database Access. It's not really a good thing to hard code your application to a specific database, especially if it's a redistributable application. (e.g. PHPBB) The ODBC calls sort of solve this, but they do require that ODBC is installed, properly configured, and compiled into your copy of PHP. (Does anyone know if any distros now have ODBC as a "standard" library?) This assumption can't be made for most OSS applications, so they tend to tell you to just use MySQL.
Indeed. As can a Farnsworth-Hirsch Fusor. The trick is to find a method for building a machine that creates energy-positive fusion. Something other than a thermonuclear warhead, that is.
(Unless someone has got a good idea for using such weapons for power generation. Anyone?)
They should use some of the technology for cold fusion to accelerate small metal plates into things... That would be hella fun!
Or turn it around and try to use railgun technology to produce warm fusion. I'm not really sure if it would work (effective confinement is one *bleeping* hard thing to do), but it might offer the possibility of fusing a large amount of matter. Now how can we extract energy from the extreme neutron flux without losing the machine in the process?
Umm... maybe I'm missing something, but the use of ROX Filer doesn't guarantee that they'll be distributing apps as bundles instead of Application Folders. The FAQ states the following:
Q. Will it be possible to install applications that have to be compiled from source, or otherwise don't easily fit into a user-friendly packaging system?
A. There will be several ways to install apps. 1. using the symphony package (the easiest way) 2. Installing via apt or directly from a deb file 3. Compiling form source (the graphical installer will attempt to do an./configure make make install if it is asked to, otherwise it can be done from the console and the program can be added to application launchers and desktop menus manually.)
They don't state anywhere that *.sym packages will be application folders. In any case, I'm downloading the Alpha so I'll know for certain very soon.:-)
However, they need to immediately stop calling it a packaging system (it's not) and start calling it "application bundles". The term "packaging system" is already heavily overloaded.
I wonder why none of the Symphony developers came to correct us?
Sorry to bust your bubble (actually I'm not, but more on that in a moment), but you've just described Internet enabled OS X DMG files. The primary difference is that you're thinking of using a read-only file system (ISO) whereas Macs have HFS+ or FFS in addition to ISO formats for their DMG files.
Before you drop the project, though, listen carefully: I think this is a GREAT idea for a project. Linux currently has nothing like this despite having all the necessary components. I think you should pursue the idea to frutition. Perhaps even get a grant from LinuxFund if you need it. Good luck!:-)
I wish people would stop bringing this up. Windows programs don't delete their settings files (and often leave their registry entries and a few program files around too!), Linux programs don't delete their settings files, in fact you'd be hard pressed to find ANY system that does this. It's a non-argument to the extreme. Sure, Apple could add a hook that deletes these files on program deletion, but that's not desirable behavior in MANY circumstances.
Well, I'm certainly not going to put words into your mouth, but I will argue against this point. I've never had a situation similar to DLL Hell on my Linux systems.
That's probably because I'm not arguing DLL Hell, but package dependency hell. i.e. Linux packaging systems often break, refuse to install something, have a missing package, etc., etc., etc. I can't count how many times I wanted to install a piece of software on Linux and simply can't find all the packages. And trying to install via source is no end of pain. Go to compile one tarball and it asks for another tarball. So you go get that, which then asks for another tarball. Which then asks for a new version of a library that's unavailable in the package repository, and won't compile on your system, and ARRRRGGHHHH! JUST SOMEBODY FRIKIN' SHOOT ME NOW!!!
The topic at hand is the Linux desktop's readiness to compete with OSX.
Actually, the topic at hand is SymphonyOS and its plans for making Linux the ultimate Desktop OS. Part of those plans are Yet Another Package Manager(TM).
I presumed that your post (often a mistake on Slashdot for sure), being the first moderated one, was on topic.
It is.
You focused criticism on package management, incorrectly ascribing to all of them a fault commonly leveled at one: RPM, and associations (to which I can't disagree)
RPM is definitely bad, but even the best ones (e.g. FreeBSD Ports) are just not userfriendly and are quite breakable.
I responded that by this standard Windows XP isn't ready either.
Here's where you fall flat. I never suggested that anything was "ready" or "not ready". You inferred that, and thus placed words in my mouth. My original intent was to ask why such a seemingly nice system targetted at desktop users is intent on using Yet Another(TM) packaging system when it has already been proven that such beasts are not friendly to end users.
And yes, XP's installer management techniques are quite poor in comparison to OS X. However, it does work reasonably well for Windows and tends to create fewer problems than many packaging systems.
The abysmal state of Slashdot moderation notwithstanding.
Just a thought, but if you wanted to not get moderated as a troll, it might help if you didn't have "troll" in your name. Walks like a duck and all...
Slashdot Mirror
I can't imagine a reasonable way to use Gmail style labels in an office environment. I'd hat to have to sort through 600 possible labels to select the right one from a drop down list.
Here's a thought: Don't use a dropdown list. Are dropdowns used to select folders today? No, a directory list is. Make it a label list, and you're gold.
And where are these labels stored anyway? On the server?
Where are folders stored anyway?
What happens when a user upgrades machines? Has to use another computer? Has to tell another employee how to find the group of files she carefully constructed?
What happens to your file system when you upgrade a machine? When you have to use another computer? Has to tell another employee how to find the group of files under labels she carefully constructed?
How does one do a reasonable data only backup in such a mess?
How does one do a reasonable backup of the mess we call hard drives?
I'm sorry, but this notion is destructive in a business environment. It's designed to make users lazy and sloppy about where they keep their data.
I'm sorry, but the only thing lazy and sloppy is your attention. What is a folder? An INode with files linked to it. What is a Label? A unique file system identity with files linked to it. What's the difference? A label can be linked to documents that other labels are linked to. Did you even catch the part about Links == Psuedo-Label functionality to cover the missing holes?
I don't understand why you're so hostile here. There's nothing new except a bit more functionality that makes things work better. Files without labels are nothing more than files stored in a root folder. (Also analogous to Google's All Email.) And separate storage devices are separate storage devices, are separate storage devices. You don't complain that mapped drives "make a huge mess that is impossible to manage" do you? So don't act like a dope about this.
Before I speak, allow me to point out that I've worked with ColdFusion for several years myself. So I know what I'm talking about when I say IT SUCKS!
The purpose of languages like Java (and by extension JSP) is to prevent programmers from making really stupid mistakes that make sites unusable. ColdFusion has NO protection against stupidity, and will happily blow up in the tinest of situations. Especially when its coupled with Stored Procedures (the 'Standard').
And yes, I'm leveling these accusations against CFMX as well. CF is just painful to work with, and creates many more problems for the programmer and users than it should.
You know, after you and others mentioned this, I dug into smart folders to figure out if they are the same. It doesn't appear to me that they are. In a Label type system, the Label shows up as if it were a folder. (See the GMail interface for an example.) The Label is precreated and unique, so you stamp it on files instead of having the info stored in multiple files. A bit like SQL keys.
If I understand Smart Folders, they only group based on a search of existing Meta-Data. It doesn't sound like there's any way to pretend like you're adding a file to a psuedo-folder. If that's the case, then Smart Folders is still a broken metaphor that needs to be expanded.
Now, let's take this into the work place, where you have 300 users and a central server. How do the users know they're working off the "official" version of the file from the server?
They should show up as different devices. i.e. I have a repository over here on the server, and over here on the desktop. This is pretty straightforward on OS X. More complex solutions in the future (which would pose some issues) could allow administrators to force all user files onto the network, then keep a "cache" of the files on the local machine for travelling laptops. (Windows has a similar feature now.)
What happens when a user makes a typo when entering meta data for associating files with a project?
Not a GMail user I assume? Look, Labels work just like folders. You create it, it looks like a folder, walks like a folder, talks like a folder, and quacks like a folder. Therefore it's a duck^H^H I mean... Folder. The primary difference between the Label and Folder is that you can have documents under multiple Labels. Links, as we use them today, are just a workaround to make up for this missing metaphor.
This is just more of Apple introducing ideas that will make actual work more difficult in the interest of letting increasingly stupid users write letters, pirate MP3s and surf for porn.
I can only assume that you've never actually USED an Apple. Because I get far more work done on my Apple than I ever do on my PC. Or perhaps you'd like to explain how ubiquitous spell checkers, applications as a file, built-in Java, files getting saved properly even if moved, automatic file associations, Expose, and a billion other USEFUL features for getting work done are only targetted at Pirates and Pr0n lovers?
It's easier than you think, actually. When it comes down to it, the primary difference a user will see between a Folder and a Label is that Folders can only hold a file once, while Labels can hold the same file multiple times. i.e. The concept just pushes existing abstractions just a bit farther.
File links have always been a sort of "hack" to get around that fact that files can only be in one folder at any given time. With a database file system, you can keep the one folder per file metaphor, or you can grow into the folders as metadata concept. Your choice.
The greatest danger in Desktop metaphors has always been that the metaphor will be taken to its fully restrictive extreme, and that the powers added by the computer will be ignored. That's exactly what's happened in this case, and it's not a good thing.
Maybe I should blog something more complete about this...
Thanks. I misunderstood what Smart Folders were. This just further underscores that Apple is the only company willing to take risks to offer useful features to their customers. I'm not quite sure what makes Wired think that Finder and Smart Folders are somehow diametric. The two are actually perfectly matched. Finder allows you to browser all the folders on your system. It's good at that. If the folders just happen to be saved queries, who really cares? The interface still works. It's just boggles my mind that no other OS has latched onto this concept before now, despite the overwhelming evidence that it's A Good Idea(TM).
Now that Apple's shown everyone the way with database filesystems, I wonder if we could get them to replace the "Recent" menu with "Piles" of recent folders. Wait, they're already looking at that. God, I love this new Apple. (i.e. NeXT renamed.) And that's coming from a guy who's hated Apple his entire life!
There's an interesting article on Wired about the interface changes in Tiger being a precursor to the demise of the classic folder-browsing Finder.
Call me when Folders become saved queries, and then we'll talk about the semi-demise of Finder. Actually, Finder wouldn't leave us at all. In a properly designed database file system, folders/directories should be replaced with standard queries. An example of this is the Labelling system in GMail. You can add a meta-data label to any email, which will then cause that email to appear in a virtual folder of the same name as the label. But if you pay attention to the search bar, you find that the folder is nothing more than a stored search on a key piece of meta-data.
This concept has massive implications for File System Usability. Under the folders-as-search concept, the same files can be organized under multiple folder groupings. This labelling data not only assists users in doing future searches for their information (i.e. A real reason to fill out meta-data other than "It might be useful."), but it also provides the user with a way of organizing ALL data for a given project under one folder without forcing the user to make a copy. It may not seem all that revolutionary, but I think you'll find that a lot of GMail users have already grasped the real power of the concept.
That being said, WHAT'S TAKING SO DAMN LONG?! This stuff was figured out 10+ years ago, and pieces of it were even included in BeOS. NTFS has had many of the necessary features since its inception (just turned off for some bloody reason), and ReiserFS is bringing the same design to Linux. So what is everyone waiting for? The next guy to scoop you on it?
*sigh* Dear Mr. Jobs: Will you please demonstrate to everyone how you do this properly with a file system? Thanks. Kudos to your NeXT development team who's made this possible.
I tried PHP, but I didn't feel it gave me the rigid OO structure and sophisticated APIs I get from Java, JSPs & Servlets.
The answer is: Two completely different markets.
JSP requires a minimum investment in hardware, resources, and server capabilities that PHP does not. JSP also tends to require more backend APIs than PHP, because you try to keep as much out of the JSP as possible. As a result, JSP tends to be the best solution for Mid to Enterprise class systems, while PHP makes a good choice for Personal to Small Business uses.
Does that answer your question?
You can easily code your SQL to be database specific if you need it that way, but that shouldn't in any way stop developers from using a generic DB access API. A DB abstraction is nothing more than a mapping of functions, so there's rarely any performance hits. Which means that applications that don't need a specific database (e.g. PHPBB anyone?) could be portable out of the gate. And even if their SQL isn't portable, that's a far easier thing to fix than attempting to add a DB abstraction after the fact.
Are you smoking crack? PHP is more inconsistent than any other language I've encountered.
Nope, I'm just a realist. PHP was designed to be a web scripting language that wrapped Unix APIs. Nothing more, nothing less. I in no way agree with the fanaticism surrounding PHP (it doesn't make a good general purpose language people!), but it does what it was designed for in a straightforward, simplistic fashion. I usually prefer to do things in JSP/Java, but if it's not an option for some reason then I prefer to use PHP over any other option. Especially over ColdFusion.
In the past two days, I have run across two separate CFM sites that crashed nonstop on simple operations. On one site, the exact same data entry would crash the first few times, then mystically work correctly. I know that a lot of people like CFM for its "simplicity", but it just doesn't cut the mustard for robust and reliable web code.
I completely agree. The primary reason why native code would be nice is that a bundled API would help put peer pressure on coders to use it. Which means that we'd see fewer "quick hacks/prototypes" (that always turn into production sites) using database specific code.
You wrote an OGG Vorbis decoder in PHP? Maybe I'm missing something, but why? That doesn't strike me as a very good language to be doing such a thing in. The "PHP Way" is to leave heavy processing like that to an external library such as libogg/libvorbis. You can then use PHP as a frontend for presenting info, streaming the data, and uploading files.
:-)
I realize that PHP can be cool at times, but one has to use the right tool for the job at hand.
Dude, you need to provide links. I had to *gasp* Google it! ;-)
:-)
For others, PEAR can be found here:
PEAR Class Repository
The Database classes of PEAR appear to be documented here:
Database Package
Looking over the DB classes, it looks like they provide a fairly decent abstraction. Thanks Quinto, that will definitely be nice for future PHP projects.
What the hell is PHP?
Probably a troll, but just in case anyone else doesn't know: PHP is a scripting language designed for generating dynamically created web pages. It functions by mixing its scripting in with the HTML, thus allowing programmers to reuse existing page designs. The scripting APIs are centered around those commonly used on Unix systems. PHP is usually bundled with Apache, so no installation tends to be required.
PHP Homepage
Congrats to the PHP development team! PHP has long followed the KISS principle while still maintaining the Unix APIs that we've all learned to know and love. While it's not the best web scripting platform for all purposes, it is a free and flexible alternative for many, many dynamic webpage projects. It's only because of PHP that so many OSS web applications have been allowed to exist.
:-)
It was slow to catch and a lot of people didn't get it.
Ok, I'm with the slow-to-catch-on part, but what's this about people not getting it? The concept had to be one of the simplest ever designed. (Thus the reason why it's so common across web scripting languages.) Here is your HTML, here's a bit of Unix scripting langauge. Simple, see?
On a slightly different topic, one wishlist item that I would like to see in PHP is Abstract Database Access. It's not really a good thing to hard code your application to a specific database, especially if it's a redistributable application. (e.g. PHPBB) The ODBC calls sort of solve this, but they do require that ODBC is installed, properly configured, and compiled into your copy of PHP. (Does anyone know if any distros now have ODBC as a "standard" library?) This assumption can't be made for most OSS applications, so they tend to tell you to just use MySQL.
Indeed. As can a Farnsworth-Hirsch Fusor. The trick is to find a method for building a machine that creates energy-positive fusion. Something other than a thermonuclear warhead, that is.
(Unless someone has got a good idea for using such weapons for power generation. Anyone?)
They should use some of the technology for cold fusion to accelerate small metal plates into things... That would be hella fun!
Or turn it around and try to use railgun technology to produce warm fusion. I'm not really sure if it would work (effective confinement is one *bleeping* hard thing to do), but it might offer the possibility of fusing a large amount of matter. Now how can we extract energy from the extreme neutron flux without losing the machine in the process?
They don't state anywhere that *.sym packages will be application folders. In any case, I'm downloading the Alpha so I'll know for certain very soon.
If that's true, then.... ROCK! :-D
However, they need to immediately stop calling it a packaging system (it's not) and start calling it "application bundles". The term "packaging system" is already heavily overloaded.
I wonder why none of the Symphony developers came to correct us?
Sorry to bust your bubble (actually I'm not, but more on that in a moment), but you've just described Internet enabled OS X DMG files. The primary difference is that you're thinking of using a read-only file system (ISO) whereas Macs have HFS+ or FFS in addition to ISO formats for their DMG files.
:-)
Before you drop the project, though, listen carefully: I think this is a GREAT idea for a project. Linux currently has nothing like this despite having all the necessary components. I think you should pursue the idea to frutition. Perhaps even get a grant from LinuxFund if you need it. Good luck!
I wish people would stop bringing this up. Windows programs don't delete their settings files (and often leave their registry entries and a few program files around too!), Linux programs don't delete their settings files, in fact you'd be hard pressed to find ANY system that does this. It's a non-argument to the extreme. Sure, Apple could add a hook that deletes these files on program deletion, but that's not desirable behavior in MANY circumstances.
Well, I'm certainly not going to put words into your mouth, but I will argue against this point. I've never had a situation similar to DLL Hell on my Linux systems.
That's probably because I'm not arguing DLL Hell, but package dependency hell. i.e. Linux packaging systems often break, refuse to install something, have a missing package, etc., etc., etc. I can't count how many times I wanted to install a piece of software on Linux and simply can't find all the packages. And trying to install via source is no end of pain. Go to compile one tarball and it asks for another tarball. So you go get that, which then asks for another tarball. Which then asks for a new version of a library that's unavailable in the package repository, and won't compile on your system, and ARRRRGGHHHH! JUST SOMEBODY FRIKIN' SHOOT ME NOW!!!
Ahem. You get the idea.
5. Nice invitation to a developers conference.
:-)
That's an invitation from the site owners, not Google. Your other points hold true. it was a fairly non-threatening, nicely worded request.
The topic at hand is the Linux desktop's readiness to compete with OSX.
Actually, the topic at hand is SymphonyOS and its plans for making Linux the ultimate Desktop OS. Part of those plans are Yet Another Package Manager(TM).
I presumed that your post (often a mistake on Slashdot for sure), being the first moderated one, was on topic.
It is.
You focused criticism on package management, incorrectly ascribing to all of them a fault commonly leveled at one: RPM, and associations (to which I can't disagree)
RPM is definitely bad, but even the best ones (e.g. FreeBSD Ports) are just not userfriendly and are quite breakable.
I responded that by this standard Windows XP isn't ready either.
Here's where you fall flat. I never suggested that anything was "ready" or "not ready". You inferred that, and thus placed words in my mouth. My original intent was to ask why such a seemingly nice system targetted at desktop users is intent on using Yet Another(TM) packaging system when it has already been proven that such beasts are not friendly to end users.
And yes, XP's installer management techniques are quite poor in comparison to OS X. However, it does work reasonably well for Windows and tends to create fewer problems than many packaging systems.
The abysmal state of Slashdot moderation notwithstanding.
Just a thought, but if you wanted to not get moderated as a troll, it might help if you didn't have "troll" in your name. Walks like a duck and all...
Should change his e-mail id to something like ths hjuhiouh@microsoft.com
No, he should change it to something like "balmer@gmail.com", then he can allow the GMail filters knock it all out.
...
Wait...