Bonus points for being mentioned in Half-Life 2 as the name of Dr. Kleiner's pet headcrab. I always assumed Hedy was a misspelling of an affectionate nickname for a headcrab...
OpenID seems to be the right approach to this. Login once (Passport-like), but to your own server -- it could be a password, a key exchange, whatever, the idea is to produce some sort of session cookie that your server can check. You can login to any other site, but through a process which doesn't give that site any kind of credentials to use on other sites, and you can restrict which sites may check your identity at all.
I'm not sure how this would protect against this kind of vulnerability, but I am convinced it's the right approach, overall, to authentication.
A continent is anything that would otherwise be considered an island, but is at least as large as Australia.
We should be able to come up with something similar for a planet. It might cause problems for Pluto, but we could certainly define it as anything orbiting a star that is not itself a star or black hole and is a coherent body at least as large as <insert arbitrary size>.
And you'd think by now that assuming you were correct, OpenOffice.org would load -- the basic app, a completely blank window -- faster than, say, AbiWord or KWord.
I realize it's not loading the entire suite, because it then takes another several seconds to open an individual app once I open that base window. You should realize that it's loading far more than it needs to, and that overall, it is still insanely bloated, even compared to Microsoft Office. I still rely on it for the few times when I need an office app, but that's really simply because "worse is better" -- it's more popular, so it gets more bugfixes and features, but the overall design is still amazingly bad.
As for commandline file conversion, I'm not the first person to have this problem, so I'd assume it's already in their issue tracker -- but where is this issue tracker? Most sites call it something like "bugzilla", and have it in a nice, easy-to-find location. I had to Google for it to find it, and that's only once you told me it's called an "issue tracker". And once I finally found it, it's a confusing and unfamiliar interface. Bugzilla is already a bit confusing if you don't know how to use it, but this is much worse. It's as if they don't want you to submit bug reports -- and, in fact, most users will either assume that a bug is their fault ("What am I doing wrong?") or completely give up on the software ("This sucks, I'm going back to MS Office!")
Regardless, I strongly suspect that this kind of thing isn't realistically possible -- like I said, any attempt to run OpenOffice, even telling it to be "headless" and not launch a GUI window, will still fail unless it can find an X server, even if it never intended to use said X server for anything.
And what did I ever say about OpenOffice and Java?
On more benefit an API has is that it can allow that change to always take effect immediately without causing the server to reload its config data during every loop.
I seem to remember a mailserver, Exim, which checked the mtime on its config file on every message received, and reloaded the data on config file change. More modern systems could easily check the file with inotify, thus responding immediately to any change, and I believe vim (and likely other text editors as well) creates a new file, then overwrites the old file with the new. Thus, a config file could, without much effort, be made just as real-time as an API. Slightly less efficient, but not in a way that really matters.
Another benefit of a config file is, it can take a lot less time to achieve almost the same amount of usability as a very good GUI. An example file, with comments, is insanely useful, and would probably take a lot longer to produce the equivalent with an API or a pref pane (to use the Mac term).
The registry is really a database that offers up a single point of failure for everything. Ooops.
I almost agreed out of spite for Microsoft, but that's not really fair. A filesystem is also a database that offers up a single point of failure for everything.
The difference is, even Microsoft seems to be able to do decent filesystems nowadays. Not good, but not horrible. The Registry, though, seems to have many other strange/stupid issues, and has no business being a central point of failure. Kind of like how I don't necessarily mind the idea of an app using HTML for some interface features -- KDE has a nice, lightweight library for "rich text" which is really a stripped-down HTML -- but under no circumstances should you embed IE. There are quicker and less painful ways of killing your app's security.
The shared library aspect does not much matter nowadays, but in previous years it mattered a lot. The system memory could only hold so much of an executable in memory at a time. It was nice to be able to unload and reload parts of your app so you could offer more features to the end user.
It still matters to me, because I like to actually share the shared libraries. And, by the way, shared != dynamic, at least on my Linux, although I believe you can dynamically load any shared library.
In any case, I glossed over this issue because I would guess that you could easily implement this yourself, unless the system was feeling especially facist with buffer overrun protection. After all, most of the more interesting languages have their own, portable systems and concepts, and most of them, even if they don't directly support dynamic libraries, should at least support enough reflection to easily implement them yourself. A language like C wouldn't make it easy, but certainly possible.
I've also used and looked at the other databases that you mentioned. I would loved to have used, and or modified the existing solutions if they would have filled those requirements for me. Then I thought, screw this. I'll just make a new database based on XML.
Funny you should choose XML. But anyway, if you really didn't find anything close (not even with the lighter-weight ones?), does your database have a name? (Is it a separate product? An open-source project?) I'm curious now.
For my own part, it always makes me happy when something will work with MySQL, because I already have a working MySQL database, and I know how to use the tools to explore and otherwise mess with the database. If I set up replication/failover, backups, etc, I only have to handle them from one program.
I would very much like a different/better solution, but in part, "worse is better" matters here -- if your program uses a custom database, especially an opaque one, that would make me nervous, as an admin. That doesn't mean I'd be completely against it, but making admins nervous is not a good thing.
Windows Vista now implements symlinks directly in the filesystem....API. And it does so in a way that breaks over networks and OSes, which is what TFA was about.
This means that.lnk files are actually more useful than these wannabe symlinks, because you can actually make them work on network shares, across OSes, and so on -- basically, anything that understands the.lnk file -- although they generally contain the full path, making things somewhat more difficult. But, symlinks are actually likely transparent to anything on the same machine, meaning your software follows symlinks by default, whereas it does not follow.lnk files by default -- you'd have to code that yourself.
And neither of them is actually part of the filesystem in the way that symlinks are on Unix.
So basically, Windows Vista (a version not out yet) is trying to approach where every Unix has been for at least 10 years, and failing miserably. Is anyone surprised?
You don't understand the difference between hardlinks and symlinks. Try again.
A hardlink has the behavior you describe. A symlink is a file which refers to another file by name, not by inode. You can have multiple hardlinks to the same symlink, as the symlink itself is just a file, and a separate file from the one it links to.
Basically I was trying to say that editing the file directly is usually bad. Editing it through a layer of inderection such as an API is good.
I wouldn't necessarily agree with that. As I said, a file format is not necessarily less stable than an API.
For instance,/etc/passwd is not likely to change. It's stable enough and abstract enough that you would not build an API around it merely to protect yourself, should the format change, because if your API is low-level enough that it's even a question, a format change would almost certainly require an API change.
There are still reasons to wrap it in an API, of course. You might want to be able to manipulate users and groups on systems that don't use a passwd file, like Windows. It saves you from having to re-implement all the best practices, like locking it, writing to a new file and renaming it on top of the old one (for atomicity), and preventing non-root users from modifying all but the most basic information about themselves.
But on that note, often OSes develop separate APIs that do essentially the same thing, and in that case, it makes sense to either port one of them or wrap them both in another API.
Regardless, I think the point of view that Linux is less scriptable because many apps use config files instead of the Registry is absurd. I concede there may be issues, but anyone who would choose one OS over another because of that should take a long, hard look at how many ways the Registry fails on a regular basis.
For example not all systems supported shared libraries in the past.
I think this could be ported, though, even within a single app.
For example there is a new Speech API that Microsoft provides. If I cared about Speech and voice recognition, then I would use that.
Why, because it's new?
I believe there are existing libraries to the same purpose. They may not be as good, so perhaps a "lowlevel" wrapper would be nice here, to allow you to use Microsoft's library for that purpose when on Windows.
There are a lot of 3d graphics applications tied to the Mac platform. The reasons are that it was easier/better/cheaper to go that route.
Weird -- Apple sold us OS X and Quartz Extreme on the basis that it's all based on OpenGL, which exists everywhere. It really shouldn't be an issue -- most 3D apps should, in fact, be at the point TFA talks about, where all you have to do is link against the local SDL (OpenGL+OpenAL) and ODE, with absolutely no platform-specific code.
I mean, I can understand a Windows-only 3D app (DirectX), but Mac-only?
I love perl... but since perl allows so much flexibility, it becomes difficult to maintain. Especially when you take over the project after some idiot was working on it. Some of the more restrictive languages don't allow you to do things that are impossible to figure out.
I doubt that, but you have more experience with this, so I'll defer to you.
For my own part, I would rather start a project in Perl, perhaps with some readability standards. Better to start with the most flexible tool possible and add restrictions than start with a bunch of restrictions, not all of them necessarily restrictions that you want. Better to start with Perl and add "use strict; use warnings;" than to start with, say, Eiffel.
As an example, I wrote my own database, just so I could have one for my applications. I can ship it with my products. I don't have to worry about it not being there. I don't have to worry about it not working, or being crappy. I don't have to worry about it being too slow. I don't have to worry about licensing, or some other stupidity.
Funny, I would definitely be worrying about it not working, being crappy, or being too slow, because I wouldn't know, without reading their code, whether anyone else had come up
If I could snap together different libraries/services like Lego (kind of the holy grail of mashups in a way) to create a wicked new app using a concept that nobody has thought of before then I'd be in heaven.
Sounds kind of like CPAN, which is open source. However, I realize that CPAN does not have to be open source in order to work.
There's many kinds of art and I think we can agree that people appreciate things in different ways.
That's true, and you've made a very good point.
However, I do think I've adequately answered the question of why someone might want to compromise some imagined future income potential and give away source code. I'm hardly a zealot, though -- I can think of projects I'd like to do myself and keep closed, for very good reasons.
I still cannot run any one OO app without launching the whole suite. You'd think by now they'd learn to make it a shared library, make it start in less than 10 seconds, etc...
I was considering using OO to convert some Word files to OpenDocument awhile ago. I ended up choosing AbiWord, because AbiWord can be run in a commandline mode to do that translation, whereas OO requires an X server and a VB-like macro to automate the process -- and the macro must be embedded in a file, and installed through the OO GUI.
So, you're absolutely right, if this was a well-architected, well-run project. It isn't.
I'm curious about the details of this. I suppose I should RTFA, but really, what more can they do to this guy other than ban him and anyone using his software?
In what way can they actually sue him for simply developing software?
Don't get me wrong, I'd very much like to see him go down, hard, even though I wish Blizzard would bother to make WoW less of a grind. But not using DMCA tactics, not if this means what I think it means. In general, providing the means to do something illegal should not, by itself, be illegal.
It raises an interesting question. I have a job, doing some web development and admining. I didn't finish so much as my first year of college.
If I were to, in my vast amounts of free time, create a nice-looking portfolio, demo, or open source game, would my resume also be reflexively tossed in the trash?
I guess what I'm asking is, should I go back to school, or should I keep working and hacking around in my spare time? (I have more spare time now than I did in school.)
But seeing as someone else on this thread has already mentioned something else, you see the problem. XML wins because Worse Is Better. I hate it, but there's not much we can do about it.
It's simple, without a graphic chips it impossible to use Linux to play pirated games.
It would be impossible anyway. The only advantage you'd have is using that Linux to try to bootstrap a pirated game, but since they were obviously lying about the PS3 including Linux on the hard drive when it ships, no PS3 game is going to be written to run under Linux -- they'll all be running on the bare metal.
Your assertion that closed source is like looking at a tiny postcard of what you'd eventually get is like arguing that you only get to look at brochures before buying a new car.
Indeed, but this wasn't about trial periods, it's about real art.
I don't know if you've ever been that proud of source code, but I can certainly imagine that if I'd built a ridiculously elegant, efficient engine, I wouldn't want the hood of the car to be sealed. People might know it was efficient and fast, but they wouldn't be able to really appreciate it.
The point is that even for someone who actually buys the software, without letting like-minded programmers see the source code, there are things about your masterpiece that no one will see or understand.
That may or may not matter. I'm guessing it doesn't matter at all to you. However, I think it is a valid reward for publishing good, open source code. I didn't think that much of Drupal until I started reading the source, and now I'm genuinely impressed.
Tell that to any commercial Linux vendor. Also, Slashdot makes money by serving up copies of other peoples content and throwing ads on top of it all.
Some commercial Linux vendors do charge a reasonable price, but it's not for the copy, it's for the support, which does take real work.
Slashdot also takes real work in developing a moderation system that actually works, and hand-picking the articles. So, even if it wasn't for Adblock, Slashdot is providing a service.
What I'm talking about is something like Windows, where you buy a copy for some $200, and you get updates, that's it. No phone tech support, no additional content, just patches to fix problems that shouldn't have been in the product to begin with.
Basically, some people will say things like "Portability issues only happpen on Windows because of the use of Windows specific API.... and Linux somehow magically escapes this problem."
Linux does not magically escape the problem. However, Linux developers are much more likely to write portable apps, because they remember how much it sucks to have their OS be unsupported, so they will naturally want to support BSD and OS X also.
POSIX does help, however. NT was originally going to claim POSIX compliance, but now seems to deliberately break it.
A buch of other people will say "All, code should be portable, because there is no reason for it to not be portable."
I wouldn't claim that. For instance, modprobe has no reason to work on anything but Linux. Similarly, regedit has no reason to work on anything but Windows. However, I would suggest that most user-level apps could be portable, and the only question is whether it costs you anything. I believe you discuss costs below:
* Less portable code makes heavy use of API that is already written and tested inside the OS.
* Less portable code can therefore be less expensive and quicker to produce. Depending on the circumstance this can be a long term and/or short term benefit.
There's a lot of vagaries there. Let's get more specific:
* Less portable code can be made to execute faster than portable code
Are you talking about the performance benefit gained by writing code that isn't as modular? Proper refactoring can have its own benefits, certainly in terms of cache coherency.
The only way you're right here is if we're talking about assembly-level optimizations. In this case, only a madman would use hand-coded assembly for more than the tightest of the tight loops, which means very little hand-coded assembly. Even here, I think it's still possible to be portable across OSes on the same arch, most of the time, and I have to wonder if this could be shunted off to a library, which could then be made platform-independent by doing similar optimizations on every platform.
For instance, if we're talking about games, the simple solution would be to use an existing engine, like the Quake4 engine, so someone else has already done the hand-optimization (as well as handled most of the other concerns), and you're automagically portable.
* Less portable code can be made to take advantage of hardware features that are only exposed through a specific API
What kind of hardware features?
Unless you're talking about what I just was, the only way this is a problem is if you're writing a driver. Driver code is generally considered part of the OS, and thus not portable. And yet, nVidia still manages to make theirs mostly portable.
* Typically the most popular OS in the world is easier to program for by most programmers, thereby allowing everyone that is hired to get up to speed on the project more quickly. (Not a concern for a team of one)
This depends on the size of a project, but most often, I find it's a much bigger job to get up to speed on the app than the environment. For instance, it's taking me far longer to learn Drupal than it took me to learn (ugh) PHP. And since it's cross-platform, the programmers can use whatever OS is easiest for them, so long as they don't screw it up for everyone else -- which is something they should already be trying to do, assuming you've already got a project.
* Typically large projects need to make every advantage in efficiency that is readily available. This might or might not be dependant on the OS
Either you mean running speed, which we discussed above, or development speed. Development speed shouldn't really matter, as you should be able to mostly use the tools everyone's familiar with, although I can see problems with people
I think you sent that as "HTML formatted" -- which gave me one big line of unreadable-ness. I haven't actually read it yet, I'll respond in a minute. Here's how I think it's supposed to look:
Basically, some people will say things like "Portability issues only happpen on Windows because of the use of Windows specific API.... and Linux somehow magically escapes this problem."
I'm sure you are already aware that it is not true, because your code is portable and uses readily available libraries that do not vary in version, or in any major way at all from OS to OS.
A buch of other people will say "All, code should be portable, because there is no reason for it to not be portable."
And, I'm sure that from your post, this is the reasoning behind your question.
So, here is a list of reasons that might help formulate an understanding of why some code is not portable... (bear in mind that a lot of my code is portable too, as that is usually indicative of good software practice)
* Less portable code makes heavy use of API that is already written and tested inside the OS. * Less portable code can therefore be less expensive and quicker to produce. Depending on the circumstance this can be a long term and/or short term benefit. * Less portable code can be made to execute faster than portable code * Less portable code can be made to take advantage of hardware features that are only exposed through a specific API * Typically the most popular OS in the world is easier to program for by most programmers, thereby allowing everyone that is hired to get up to speed on the project more quickly. (Not a concern for a team of one) * Typically large projects need to make every advantage in efficiency that is readily available. This might or might not be dependant on the OS * Anything that has to do a lot of work with filesystems will need operating system dependant code to be written. There are faster file operation system calls for each specific OS. * Less portable code can be made smaller in size, by depending on libraries that are only available on a target OS. (As long as they are actually there!!!)
For example in Windows you can take advantage of a bunch of API to change system settings like IIS settings, and smtp settings.
In Linux you have to write code to manually change text files. Of course API are better here because then there is less chance messing up the format of the text file. And your code will work in the next version of the OS too. Your code will not work in the next version if you change the config files manually. In your case, you don't care because you are just writing little free utilities. In bigger enterprise level applications you need to care about things like this. There are many examples of needing to use API where-ever possible. More experience with bigger applications is the best way to get to this knowledge.
Also, one final note. C is getting to be an old language now, and it is sad that any code written in C is not portable. Things that have been around that long, have workaround after workaround to make them keep from breaking. It almost requires effort to write C code that is not portable nowadays. Bad C code is still prevelant though. This is mostly due to the #define conditional that was included to make C a lasting language. It worked. Now let's be done with it.
Moving forward, I would suggest a language that makes use of garbage collection as your next choice. Also, one with clean syntax and no workarounds already in place would be a good plan. These criterea make for a langauge that is more difficult to write stupid code in. If you ever have to maintain code, then these are good considerations.
Here are some examples (in no specific oreder) Java, C#, PHP
Depending on third party code and libraries is absolutely foolish
You know what? You're right. I'm writing my next app in hand-coded binary, written in my own hex editor, just so I don't have to depend on anybody else's code.
</sarcasm>
I agree in part -- don't depend on libraries you can't control. But do depend on libraries to which you can get the source code -- that way, if there's a problem, you can fix it, and if there's no problem, you just saved yourself a whole shitload of work.
And by the way, why did you bring up Java at all? Sure, Java can easily be cross-platform, but was the word even mentioned before you went on this rant? How, exactly, does Sun propaganda suggest that portability is hard?
Sure you can sell painting support services, but 99.9% of people just want the standard painting. [How may pay to customize the Apache web server?]
More than you'd expect. Like I said, I'm paid to develop Drupal. If people were 100% satisfied with the software that was out there, especially the free/OSS stuff, I'd be out of a job.
Closed source is like painting the Sistine Chapel but putting up a sign saying "If you want yours painted like this, please contact Michelangelo's Painting Blueprints at 1-800-ARTWORK".
No, it is not. Closed source is like painting the Sistine Chapel but locking the building and selling tiny postcards with photographs of it. No one ever gets to see it as you really intended it to be appreciated. The sign that says "If you want yours painted like this" is more of an open source kind of thing, because it actually takes a huge amount of work to paint another chapel, whereas it takes no work at all to offer another download of your closed source software.
Oh, and the guy who's in charge of distributing postcards will stop you halfway through and say "That's enough, we can just zoom in on this bit and people will buy our postcards," so not even you get to see it as it was intended.
Since you haven't given away the means to have it painted at no cost to them, you can make more money. You can still sell painting support services, but your main income comes from simply duplicating the blueprints at little cost to you and profiting huge.
This is only one business model, and I like mine better. I get paid by the hour, not for results, which means I get to do it right, not just whatever will sell.
By the way, I personally see it as just a bit unethical that you can make a fortune off of copies. Think about it. I'm working, every day, and I get paid for the work I put in. If I'm successful, everyone's happy, and I might get to work on more interesting things, or get paid more. However, you're not paid for your work at all -- you're paid for something you created. This also means you could decide to never work another day in your life, and as long as your postcards keep selling, you're fat and happy.
On the flipside, you may come up with something that no one really wants, or at least, that no one wants to spend money on. Certainly, something that's a fad -- eventually, all the Sistine Chapel postcards are gone. Except in software, as we keep progressing, there's more and more chance that old, unmaintained software won't continue to work on new machines, especially if it's closed, DRM'd stuff -- for instance, some games that relied on physical properties of the floppy disks on which they were shipped have been pretty much lost forever.
Open source guarantees that your software, your masterpiece, is around forever, in the same way that open standard file formats ensure that your word processing files are around forever. Even if it's not maintained, the source code is still there, so it's still possible for someone, at some point in the future, to dig up your old code and bring it up-to-date. Certainly, id software would not have been willing to spend the resources to keep Doom and Doom II working on modern computers, much less give them real Internet play and better lighting and effects.
You may get lucky with closed source, but more likely, your masterpiece will be a "trade secret", so if the company loses interest in it, even if it's no longer profitable, it dies. Open source, everyone owns at least enough rights to continue to keep it up-to-date, so even if your company completely loses interest in it, you can go back and work with it.
However, I suspect that not much of this matters to you if you're the kind of person who turns the Sistine Chapel into 1-800-ARTWORK.
Personally, I don't develop software just so that I can be an anonymous contributor to future technology. I do it to pay the rent, buy cars, etc.
First of all, you're not anonymous. Just look at Linus. But regardless:
I am currently employed by a local company, a small business who runs a Drupal site.
Drupal currently covers most, but not all of their needs. Thus, I am paid to fill that gap. Any changes I make, I am free to release back to the community, but I make my paycheck either way.
The same is true of any other project I do for them, and I do have one that is almost ready to release (although it'll be ugly as sin when I do).
What you're missing is the true value of software as a service, beyond just the slogan. I am paid for the service of developing software for this company. The company has no plans whatsoever to sell this software, it just fills a need. I use open source, not just for the warm fuzzies, but because I can more easily mess with the internals, and because it's better to start with software that mostly does what you want than to start from scratch. I give back to the community, not just for the warm fuzzies, but because that way, I don't have to maintain my own independent branch -- if my patches are merged into mainline, I don't have to be on a constant treadmill of keeping them up-to-date -- someone else can maintain them.
And since everyone does this, I gain the benefit of other people in the same situation at other companies. Drupal is pretty generic software, too, and we're a pretty niche company, so the argument of "we're helping our competitors" doesn't hold much water. Besides, even if we were, they'd have to be helping us just as much.
And I'm not being sarcastic with that, I genuinely don't understand why anyone would want to share the fundamentals of their creation in a way that would compromise any potential future earnings.
Well, consider two possibilities:
1) Michaelangelo is commissioned to paint a wealthy person's bedroom.
2) Michaelangelo paints the Sistine Chapel. (Am I spelling that right?)
Which Michaelangelo would you rather be?
At first glance, #1 seems like the better idea. You make more money, because every wealthy person wants your paintings in their bedroom, so they each have to pay you for the same painting. But even if it's just about money, don't you think Michaelangelo #2 is better off? Even if he isn't paid for the Sistene Chapel, a hell of a lot more wealthy people know about him. Even if they can all visit the Chapel and see his painting for free, they might commission him to paint some things of theirs anyway.
But consider that sometimes money is not an issue. Suppose that both Michaelangelos are wealthy beyond their wildest dreams, and they don't have to work at all. If you were going to paint at all, which would you rather paint? Or suppose they're both equally impoverished, and have to work a day job anyway -- which Michaelangelo would you rather be?
Some unknown bedroom painter? Or someone world-famous for amazing artwork, that everyone else can analyze in the smallest detail and appreciate your genius?
That's part of why people would contribute, even if we weren't paid to do so, even if we didn't have a personal itch. (That is still valid, by the way -- I can mess with my own kernel, and I do, without having to write a new one from scratch, never mind that I can't possibly sell my changes. I couldn't sell a new kernel, either.)
People contribute because, if you're good, open source means people know you're good. You can become a legend that way. Richard Stallman, Larry Wall, Linus Torvalds, Matz, even lesser gods like Andrew Morton, Andrea Archangeli... Can you name a single developer at Microsoft? Because I sure as hell can't. The only person I can think of who is famous for developing commercial software is John Carmack, and he's releasing all his old code anyway.
Slashdot Mirror
Hit 'em where it hurts.
Bonus points for being mentioned in Half-Life 2 as the name of Dr. Kleiner's pet headcrab. I always assumed Hedy was a misspelling of an affectionate nickname for a headcrab...
OpenID seems to be the right approach to this. Login once (Passport-like), but to your own server -- it could be a password, a key exchange, whatever, the idea is to produce some sort of session cookie that your server can check. You can login to any other site, but through a process which doesn't give that site any kind of credentials to use on other sites, and you can restrict which sites may check your identity at all.
I'm not sure how this would protect against this kind of vulnerability, but I am convinced it's the right approach, overall, to authentication.
Yes it would, and Firefox will already do that for you, I believe.
A continent is anything that would otherwise be considered an island, but is at least as large as Australia.
We should be able to come up with something similar for a planet. It might cause problems for Pluto, but we could certainly define it as anything orbiting a star that is not itself a star or black hole and is a coherent body at least as large as <insert arbitrary size>.
And you'd think by now that assuming you were correct, OpenOffice.org would load -- the basic app, a completely blank window -- faster than, say, AbiWord or KWord.
I realize it's not loading the entire suite, because it then takes another several seconds to open an individual app once I open that base window. You should realize that it's loading far more than it needs to, and that overall, it is still insanely bloated, even compared to Microsoft Office. I still rely on it for the few times when I need an office app, but that's really simply because "worse is better" -- it's more popular, so it gets more bugfixes and features, but the overall design is still amazingly bad.
As for commandline file conversion, I'm not the first person to have this problem, so I'd assume it's already in their issue tracker -- but where is this issue tracker? Most sites call it something like "bugzilla", and have it in a nice, easy-to-find location. I had to Google for it to find it, and that's only once you told me it's called an "issue tracker". And once I finally found it, it's a confusing and unfamiliar interface. Bugzilla is already a bit confusing if you don't know how to use it, but this is much worse. It's as if they don't want you to submit bug reports -- and, in fact, most users will either assume that a bug is their fault ("What am I doing wrong?") or completely give up on the software ("This sucks, I'm going back to MS Office!")
Regardless, I strongly suspect that this kind of thing isn't realistically possible -- like I said, any attempt to run OpenOffice, even telling it to be "headless" and not launch a GUI window, will still fail unless it can find an X server, even if it never intended to use said X server for anything.
And what did I ever say about OpenOffice and Java?
I seem to remember a mailserver, Exim, which checked the mtime on its config file on every message received, and reloaded the data on config file change. More modern systems could easily check the file with inotify, thus responding immediately to any change, and I believe vim (and likely other text editors as well) creates a new file, then overwrites the old file with the new. Thus, a config file could, without much effort, be made just as real-time as an API. Slightly less efficient, but not in a way that really matters.
Another benefit of a config file is, it can take a lot less time to achieve almost the same amount of usability as a very good GUI. An example file, with comments, is insanely useful, and would probably take a lot longer to produce the equivalent with an API or a pref pane (to use the Mac term).
I almost agreed out of spite for Microsoft, but that's not really fair. A filesystem is also a database that offers up a single point of failure for everything.
The difference is, even Microsoft seems to be able to do decent filesystems nowadays. Not good, but not horrible. The Registry, though, seems to have many other strange/stupid issues, and has no business being a central point of failure. Kind of like how I don't necessarily mind the idea of an app using HTML for some interface features -- KDE has a nice, lightweight library for "rich text" which is really a stripped-down HTML -- but under no circumstances should you embed IE. There are quicker and less painful ways of killing your app's security.
It still matters to me, because I like to actually share the shared libraries. And, by the way, shared != dynamic, at least on my Linux, although I believe you can dynamically load any shared library.
In any case, I glossed over this issue because I would guess that you could easily implement this yourself, unless the system was feeling especially facist with buffer overrun protection. After all, most of the more interesting languages have their own, portable systems and concepts, and most of them, even if they don't directly support dynamic libraries, should at least support enough reflection to easily implement them yourself. A language like C wouldn't make it easy, but certainly possible.
Funny you should choose XML. But anyway, if you really didn't find anything close (not even with the lighter-weight ones?), does your database have a name? (Is it a separate product? An open-source project?) I'm curious now.
For my own part, it always makes me happy when something will work with MySQL, because I already have a working MySQL database, and I know how to use the tools to explore and otherwise mess with the database. If I set up replication/failover, backups, etc, I only have to handle them from one program.
I would very much like a different/better solution, but in part, "worse is better" matters here -- if your program uses a custom database, especially an opaque one, that would make me nervous, as an admin. That doesn't mean I'd be completely against it, but making admins nervous is not a good thing.
Actually, it makes NT. Apparently not, then.
Windows Vista now implements symlinks directly in the filesystem....API. And it does so in a way that breaks over networks and OSes, which is what TFA was about.
.lnk files are actually more useful than these wannabe symlinks, because you can actually make them work on network shares, across OSes, and so on -- basically, anything that understands the .lnk file -- although they generally contain the full path, making things somewhat more difficult. But, symlinks are actually likely transparent to anything on the same machine, meaning your software follows symlinks by default, whereas it does not follow .lnk files by default -- you'd have to code that yourself.
This means that
And neither of them is actually part of the filesystem in the way that symlinks are on Unix.
So basically, Windows Vista (a version not out yet) is trying to approach where every Unix has been for at least 10 years, and failing miserably. Is anyone surprised?
You don't understand the difference between hardlinks and symlinks. Try again.
A hardlink has the behavior you describe. A symlink is a file which refers to another file by name, not by inode. You can have multiple hardlinks to the same symlink, as the symlink itself is just a file, and a separate file from the one it links to.
You do realize how that works, right? XP can mount an ext3 FS, but only as ext2. That means no journaling. That means FAT-like [in]stability.
I wouldn't necessarily agree with that. As I said, a file format is not necessarily less stable than an API.
For instance, /etc/passwd is not likely to change. It's stable enough and abstract enough that you would not build an API around it merely to protect yourself, should the format change, because if your API is low-level enough that it's even a question, a format change would almost certainly require an API change.
There are still reasons to wrap it in an API, of course. You might want to be able to manipulate users and groups on systems that don't use a passwd file, like Windows. It saves you from having to re-implement all the best practices, like locking it, writing to a new file and renaming it on top of the old one (for atomicity), and preventing non-root users from modifying all but the most basic information about themselves.
But on that note, often OSes develop separate APIs that do essentially the same thing, and in that case, it makes sense to either port one of them or wrap them both in another API.
Regardless, I think the point of view that Linux is less scriptable because many apps use config files instead of the Registry is absurd. I concede there may be issues, but anyone who would choose one OS over another because of that should take a long, hard look at how many ways the Registry fails on a regular basis.
I think this could be ported, though, even within a single app.
Why, because it's new?
I believe there are existing libraries to the same purpose. They may not be as good, so perhaps a "lowlevel" wrapper would be nice here, to allow you to use Microsoft's library for that purpose when on Windows.
Weird -- Apple sold us OS X and Quartz Extreme on the basis that it's all based on OpenGL, which exists everywhere. It really shouldn't be an issue -- most 3D apps should, in fact, be at the point TFA talks about, where all you have to do is link against the local SDL (OpenGL+OpenAL) and ODE, with absolutely no platform-specific code.
I mean, I can understand a Windows-only 3D app (DirectX), but Mac-only?
I doubt that, but you have more experience with this, so I'll defer to you.
For my own part, I would rather start a project in Perl, perhaps with some readability standards. Better to start with the most flexible tool possible and add restrictions than start with a bunch of restrictions, not all of them necessarily restrictions that you want. Better to start with Perl and add "use strict; use warnings;" than to start with, say, Eiffel.
Funny, I would definitely be worrying about it not working, being crappy, or being too slow, because I wouldn't know, without reading their code, whether anyone else had come up
Sounds kind of like CPAN, which is open source. However, I realize that CPAN does not have to be open source in order to work.
That's true, and you've made a very good point.
However, I do think I've adequately answered the question of why someone might want to compromise some imagined future income potential and give away source code. I'm hardly a zealot, though -- I can think of projects I'd like to do myself and keep closed, for very good reasons.
I still cannot run any one OO app without launching the whole suite. You'd think by now they'd learn to make it a shared library, make it start in less than 10 seconds, etc...
I was considering using OO to convert some Word files to OpenDocument awhile ago. I ended up choosing AbiWord, because AbiWord can be run in a commandline mode to do that translation, whereas OO requires an X server and a VB-like macro to automate the process -- and the macro must be embedded in a file, and installed through the OO GUI.
So, you're absolutely right, if this was a well-architected, well-run project. It isn't.
I'm curious about the details of this. I suppose I should RTFA, but really, what more can they do to this guy other than ban him and anyone using his software?
In what way can they actually sue him for simply developing software?
Don't get me wrong, I'd very much like to see him go down, hard, even though I wish Blizzard would bother to make WoW less of a grind. But not using DMCA tactics, not if this means what I think it means. In general, providing the means to do something illegal should not, by itself, be illegal.
...Oh wait, they renamed that to Vista. Nevermind, flaccid it is!
It raises an interesting question. I have a job, doing some web development and admining. I didn't finish so much as my first year of college.
If I were to, in my vast amounts of free time, create a nice-looking portfolio, demo, or open source game, would my resume also be reflexively tossed in the trash?
I guess what I'm asking is, should I go back to school, or should I keep working and hacking around in my spare time? (I have more spare time now than I did in school.)
But seeing as someone else on this thread has already mentioned something else, you see the problem. XML wins because Worse Is Better. I hate it, but there's not much we can do about it.
It would be impossible anyway. The only advantage you'd have is using that Linux to try to bootstrap a pirated game, but since they were obviously lying about the PS3 including Linux on the hard drive when it ships, no PS3 game is going to be written to run under Linux -- they'll all be running on the bare metal.
Indeed, but this wasn't about trial periods, it's about real art.
I don't know if you've ever been that proud of source code, but I can certainly imagine that if I'd built a ridiculously elegant, efficient engine, I wouldn't want the hood of the car to be sealed. People might know it was efficient and fast, but they wouldn't be able to really appreciate it.
The point is that even for someone who actually buys the software, without letting like-minded programmers see the source code, there are things about your masterpiece that no one will see or understand.
That may or may not matter. I'm guessing it doesn't matter at all to you. However, I think it is a valid reward for publishing good, open source code. I didn't think that much of Drupal until I started reading the source, and now I'm genuinely impressed.
Some commercial Linux vendors do charge a reasonable price, but it's not for the copy, it's for the support, which does take real work.
Slashdot also takes real work in developing a moderation system that actually works, and hand-picking the articles. So, even if it wasn't for Adblock, Slashdot is providing a service.
What I'm talking about is something like Windows, where you buy a copy for some $200, and you get updates, that's it. No phone tech support, no additional content, just patches to fix problems that shouldn't have been in the product to begin with.
Linux does not magically escape the problem. However, Linux developers are much more likely to write portable apps, because they remember how much it sucks to have their OS be unsupported, so they will naturally want to support BSD and OS X also.
POSIX does help, however. NT was originally going to claim POSIX compliance, but now seems to deliberately break it.
I wouldn't claim that. For instance, modprobe has no reason to work on anything but Linux. Similarly, regedit has no reason to work on anything but Windows. However, I would suggest that most user-level apps could be portable, and the only question is whether it costs you anything. I believe you discuss costs below:
There's a lot of vagaries there. Let's get more specific:
Are you talking about the performance benefit gained by writing code that isn't as modular? Proper refactoring can have its own benefits, certainly in terms of cache coherency.
The only way you're right here is if we're talking about assembly-level optimizations. In this case, only a madman would use hand-coded assembly for more than the tightest of the tight loops, which means very little hand-coded assembly. Even here, I think it's still possible to be portable across OSes on the same arch, most of the time, and I have to wonder if this could be shunted off to a library, which could then be made platform-independent by doing similar optimizations on every platform.
For instance, if we're talking about games, the simple solution would be to use an existing engine, like the Quake4 engine, so someone else has already done the hand-optimization (as well as handled most of the other concerns), and you're automagically portable.
What kind of hardware features?
Unless you're talking about what I just was, the only way this is a problem is if you're writing a driver. Driver code is generally considered part of the OS, and thus not portable. And yet, nVidia still manages to make theirs mostly portable.
This depends on the size of a project, but most often, I find it's a much bigger job to get up to speed on the app than the environment. For instance, it's taking me far longer to learn Drupal than it took me to learn (ugh) PHP. And since it's cross-platform, the programmers can use whatever OS is easiest for them, so long as they don't screw it up for everyone else -- which is something they should already be trying to do, assuming you've already got a project.
Either you mean running speed, which we discussed above, or development speed. Development speed shouldn't really matter, as you should be able to mostly use the tools everyone's familiar with, although I can see problems with people
I think you sent that as "HTML formatted" -- which gave me one big line of unreadable-ness. I haven't actually read it yet, I'll respond in a minute. Here's how I think it's supposed to look:
Basically, some people will say things like "Portability issues only happpen on Windows because of the use of Windows specific API.... and Linux somehow magically escapes this problem."
I'm sure you are already aware that it is not true, because your code is portable and uses readily available libraries that do not vary in version, or in any major way at all from OS to OS.
A buch of other people will say "All, code should be portable, because there is no reason for it to not be portable."
And, I'm sure that from your post, this is the reasoning behind your question.
So, here is a list of reasons that might help formulate an understanding of why some code is not portable... (bear in mind that a lot of my code is portable too, as that is usually indicative of good software practice)
* Less portable code makes heavy use of API that is already written and tested inside the OS.
* Less portable code can therefore be less expensive and quicker to produce. Depending on the circumstance this can be a long term and/or short term benefit.
* Less portable code can be made to execute faster than portable code
* Less portable code can be made to take advantage of hardware features that are only exposed through a specific API
* Typically the most popular OS in the world is easier to program for by most programmers, thereby allowing everyone that is hired to get up to speed on the project more quickly. (Not a concern for a team of one)
* Typically large projects need to make every advantage in efficiency that is readily available. This might or might not be dependant on the OS
* Anything that has to do a lot of work with filesystems will need operating system dependant code to be written. There are faster file operation system calls for each specific OS.
* Less portable code can be made smaller in size, by depending on libraries that are only available on a target OS. (As long as they are actually there!!!)
For example in Windows you can take advantage of a bunch of API to change system settings like IIS settings, and smtp settings.
In Linux you have to write code to manually change text files. Of course API are better here because then there is less chance messing up the format of the text file. And your code will work in the next version of the OS too. Your code will not work in the next version if you change the config files manually. In your case, you don't care because you are just writing little free utilities. In bigger enterprise level applications you need to care about things like this. There are many examples of needing to use API where-ever possible. More experience with bigger applications is the best way to get to this knowledge.
Also, one final note. C is getting to be an old language now, and it is sad that any code written in C is not portable. Things that have been around that long, have workaround after workaround to make them keep from breaking. It almost requires effort to write C code that is not portable nowadays. Bad C code is still prevelant though. This is mostly due to the #define conditional that was included to make C a lasting language. It worked. Now let's be done with it.
Moving forward, I would suggest a language that makes use of garbage collection as your next choice. Also, one with clean syntax and no workarounds already in place would be a good plan. These criterea make for a langauge that is more difficult to write stupid code in. If you ever have to maintain code, then these are good considerations.
Here are some examples (in no specific oreder)
Java, C#, PHP
Here is a bad example
C++
You know what? You're right. I'm writing my next app in hand-coded binary, written in my own hex editor, just so I don't have to depend on anybody else's code.
</sarcasm>
I agree in part -- don't depend on libraries you can't control. But do depend on libraries to which you can get the source code -- that way, if there's a problem, you can fix it, and if there's no problem, you just saved yourself a whole shitload of work.
And by the way, why did you bring up Java at all? Sure, Java can easily be cross-platform, but was the word even mentioned before you went on this rant? How, exactly, does Sun propaganda suggest that portability is hard?
More than you'd expect. Like I said, I'm paid to develop Drupal. If people were 100% satisfied with the software that was out there, especially the free/OSS stuff, I'd be out of a job.
No, it is not. Closed source is like painting the Sistine Chapel but locking the building and selling tiny postcards with photographs of it. No one ever gets to see it as you really intended it to be appreciated. The sign that says "If you want yours painted like this" is more of an open source kind of thing, because it actually takes a huge amount of work to paint another chapel, whereas it takes no work at all to offer another download of your closed source software.
Oh, and the guy who's in charge of distributing postcards will stop you halfway through and say "That's enough, we can just zoom in on this bit and people will buy our postcards," so not even you get to see it as it was intended.
This is only one business model, and I like mine better. I get paid by the hour, not for results, which means I get to do it right, not just whatever will sell.
By the way, I personally see it as just a bit unethical that you can make a fortune off of copies. Think about it. I'm working, every day, and I get paid for the work I put in. If I'm successful, everyone's happy, and I might get to work on more interesting things, or get paid more. However, you're not paid for your work at all -- you're paid for something you created. This also means you could decide to never work another day in your life, and as long as your postcards keep selling, you're fat and happy.
On the flipside, you may come up with something that no one really wants, or at least, that no one wants to spend money on. Certainly, something that's a fad -- eventually, all the Sistine Chapel postcards are gone. Except in software, as we keep progressing, there's more and more chance that old, unmaintained software won't continue to work on new machines, especially if it's closed, DRM'd stuff -- for instance, some games that relied on physical properties of the floppy disks on which they were shipped have been pretty much lost forever.
Open source guarantees that your software, your masterpiece, is around forever, in the same way that open standard file formats ensure that your word processing files are around forever. Even if it's not maintained, the source code is still there, so it's still possible for someone, at some point in the future, to dig up your old code and bring it up-to-date. Certainly, id software would not have been willing to spend the resources to keep Doom and Doom II working on modern computers, much less give them real Internet play and better lighting and effects.
You may get lucky with closed source, but more likely, your masterpiece will be a "trade secret", so if the company loses interest in it, even if it's no longer profitable, it dies. Open source, everyone owns at least enough rights to continue to keep it up-to-date, so even if your company completely loses interest in it, you can go back and work with it.
However, I suspect that not much of this matters to you if you're the kind of person who turns the Sistine Chapel into 1-800-ARTWORK.
First of all, you're not anonymous. Just look at Linus. But regardless:
I am currently employed by a local company, a small business who runs a Drupal site.
Drupal currently covers most, but not all of their needs. Thus, I am paid to fill that gap. Any changes I make, I am free to release back to the community, but I make my paycheck either way.
The same is true of any other project I do for them, and I do have one that is almost ready to release (although it'll be ugly as sin when I do).
What you're missing is the true value of software as a service, beyond just the slogan. I am paid for the service of developing software for this company. The company has no plans whatsoever to sell this software, it just fills a need. I use open source, not just for the warm fuzzies, but because I can more easily mess with the internals, and because it's better to start with software that mostly does what you want than to start from scratch. I give back to the community, not just for the warm fuzzies, but because that way, I don't have to maintain my own independent branch -- if my patches are merged into mainline, I don't have to be on a constant treadmill of keeping them up-to-date -- someone else can maintain them.
And since everyone does this, I gain the benefit of other people in the same situation at other companies. Drupal is pretty generic software, too, and we're a pretty niche company, so the argument of "we're helping our competitors" doesn't hold much water. Besides, even if we were, they'd have to be helping us just as much.
Well, consider two possibilities:
1) Michaelangelo is commissioned to paint a wealthy person's bedroom.
2) Michaelangelo paints the Sistine Chapel. (Am I spelling that right?)
Which Michaelangelo would you rather be?
At first glance, #1 seems like the better idea. You make more money, because every wealthy person wants your paintings in their bedroom, so they each have to pay you for the same painting. But even if it's just about money, don't you think Michaelangelo #2 is better off? Even if he isn't paid for the Sistene Chapel, a hell of a lot more wealthy people know about him. Even if they can all visit the Chapel and see his painting for free, they might commission him to paint some things of theirs anyway.
But consider that sometimes money is not an issue. Suppose that both Michaelangelos are wealthy beyond their wildest dreams, and they don't have to work at all. If you were going to paint at all, which would you rather paint? Or suppose they're both equally impoverished, and have to work a day job anyway -- which Michaelangelo would you rather be?
Some unknown bedroom painter? Or someone world-famous for amazing artwork, that everyone else can analyze in the smallest detail and appreciate your genius?
That's part of why people would contribute, even if we weren't paid to do so, even if we didn't have a personal itch. (That is still valid, by the way -- I can mess with my own kernel, and I do, without having to write a new one from scratch, never mind that I can't possibly sell my changes. I couldn't sell a new kernel, either.)
People contribute because, if you're good, open source means people know you're good. You can become a legend that way. Richard Stallman, Larry Wall, Linus Torvalds, Matz, even lesser gods like Andrew Morton, Andrea Archangeli... Can you name a single developer at Microsoft? Because I sure as hell can't. The only person I can think of who is famous for developing commercial software is John Carmack, and he's releasing all his old code anyway.