Don't take this the wrong way but that is seemingly exactly an ideal project for which MySQL was made for. Data access appears to be primarily read-only with none of it being critical. Worse case, if the database becomes corrupt, you simply restore the whole thing from back up. Since the data doesn't appear (based on description) to be changing rapidly (if at all or perhaps backend updates only), issue such as online back or high availability is likely not to be an issue in the least. If they were, they'd probably be using that Oracle license.
Always remember that table statistics are used for approximate best guesses for inputs to the query optimizer. It is not uncommon or unheard of to actually see somes types of queries run slower after table statistics have been updated. I've seen this on Oracle, Sybase and SQL Server. I doubt that this is an issue unique to those RDBMS since the conceptual implementations and basis for algorithms tend to all be more or less the same.
Again, I plead ignorance about the implementation details. Simply put, I find it hard to believe that such a thing is an issue. Unless you have specific instances to cite rather than broad and general speculations about a specific implementation which neither of us seem to know anything about, your comment is seemingly without merit.
Agreed, a reliable SM system does require some sort of locking mechanism, but this hardly requires the transport to support this. Again, I could talk until I'm blue in the face about guesses as to why this isn't a concern however it would simply be a guess...as is your concern.
Simple question. Did it say that they use standard FTP daemons or that they use the FTP protocol? If they are using a standard server then clearly you are going to be limited by the constraints of that server's feature set, however, if they are simply using the FTP protocol, then your comments are completely unfounded. Either way, I can easily imagine mechanisms which avoid your issue all together, so as far as I'm concerned, it's a moot issue.
In a nut shell, I can't understand how your comment was mod'ed +1.
First, let me say that I use Gnome for my desktop and have used GTK+ for sizable projects. I've even developed smaller GNOME applications and found the various API's horrible. I can't stress enough that I'm not trying to cook someone here for the sake of cooking. I think the only point he makes here is that GNOME is without a solid technology direction and has suffered dearly for it for a very long time. In fact, he as much as points this out. So, call me a troll if you like but I fail to see how Mono isn't anything other than a new tech headline. Please read below if you care to follow his assumptions while he explains pretty much nothing.
The CIL and the promise of language independence
This is what CORBA promised more or less. Please correct me if I'm wrong, but didn't Gnome start out using CORBA and decided that it needed different technologies later in the cycle?
Are there not already language bindings for C, C++, Python, Perl and I'm sure several others? So tell me again why we need an interpretted wanna-be CORBA in the mix?
This technology allows programming languages to be considered on the basis of how they will perform for a given task, and not based on the runtime libraries that you will depend. Any software engineer should read this article:
Generally speaking, good engineers already do this. The choice of yet another tool somehow doesn't make this happen, though, choice can be a good thing. Adding a slow runtime is not going to make the awesomely optimized FORTAN libs suddenly appear and become compatible with various CIL implementations. In fact, really all you can say is that when you use this technology [CIL implementations], the language of choice will no longer effect performance rather it will be forced back onto the developers to optimize for a given language; that is, language specific CIL tuning tricks. On the other hand, all of the languages which use this are going to have a negative performance impact so it sounds like programmers will have even more choice (seemingly pointless). Let's see, I can pick C or C++ for performance or I can pick C/C++/C# [CIL implementations] which performs an order of magnitude slower. Hmmm. Hard choice. Tell me again why I should care about CIL, Mono and C#??
GNOME had always tried to have a good support for multiple programming languages.
No it hasn't. Save only for the CORBA efforts, GNOME is very C biased. One of the common complaints coming from the C++ KDE camp. The more correct statement would be, "multiple programming languages have always tried to support GNOME." These efforts have inflicted various levels of pain on their bindings implementors.
They have incorporated many ideas from Java, and they have extended it to address new needs that developers had. They took where Java left off.
What does that mean? Sounds like they are re-implementing Java. Why? Why don't you just further improve Java. I'll make it known here, I've never beena Java fan but this just doesn't make sense to me. It only makes sense to Microsoft because they badly need to de-crown Java. Aside from Microsoft, I don't see how this helps anyone. By the way, what are these "new needs that developers had", that existing technologies can't address? Do we really have to move to a VM to address these needs?? Somehow this seems like we're taking several steps backward. Anyone?
Libraries have been built by disconnected groups (PNG, JPEG, Gtk+, Xml, Bonobo, CORBA spec apis, etc) and the end result is that a developer eventually has to learn more than he wanted to in the course of developing a large application.
Might this have more to do with the fact that GNOME has been wondering without direction for a very long time and no one in the GNOME camp has been willing to settle and agree on a single API nor the technology behind these APIs? Does it have to be the programmer's fault? Can't it be that the API's provided have just sucked? Can't it be that the API's have changed so fast and often that programmers wonder what they are doing trying to implement a large application via GNOME? Can't this mean that the implementations behind the API's have been less than wonderful and seemingly change daily? Does it have to be because programmers don't want to learn? Seems to me, if programmers didn't want to learn, they wouldn't be trying to develope large applications in a highly dynamic environment (from an API perspective). Wouldn't a static API help address this? Won't simply adding yet another API compound this issue even further?
There is a point in your life when you realize that you have written enough destructors, and have spent enough time tracking down a memory leak, and you have spend enough time tracking down memory corruption, and you have spent enough time using low-level insecure functions, and you have implemented way too many linked lists [1]
Doesn't this really reflect the choice of underpinning APIs and implementations behind the APIs as much as the language. It's funny, I've developed very large applications (C/C++) before and never had nearly as many issues as one does when trying to use the GNOME/GTK technologies. Might it be that you've been chasing the wrong end of the technology spectrum? Might it be that you should of been looking to replace GTK and the billion other obtuse libraries that are the foundation of GNOME with better, faster, stronger technologies? Might is be that the number of memory leaks and associated debugging issues have something to do with design skills and/or coding habits? In not in whole, in part? Some part? Maybe a little? If you have even a small problem which is compounded over and over in various suite of libs that is GNOME, might this actually result in a large problem manifesting it self as obtuse APIs which lend them self to these issues?
Evolution took us two years to develop and at its peak had 17 engineers working on the project. I want to be able to deliver four times as many free software applications with the same resources, and I believe that this is achievable with these new technologies.
Wow! This really is magic technology1 It's going to 4x the level of productivity over any other tool, toolkit, and language. Wow! Does it come with a bridge too? I can't wait.
Even C++ was invented at ATT.
Yes, you're right, however, it was written by people who wanted to look at solving real problems with a different approach while leveraging the large C programmer base. It was need driven. The same can not be said for C# and CIL. Both of these are being driven my Microsoft to side step Sun and Java. The motive is as important as anything else, especially when we are talking about Microsoft. If, according to you, it's pretty much Java with some icing, why not go the shortest and best path for everyone and help improve Java? Go ahead, make the icing for Java. Then, you'll have everything you're asking for with a whole lot less effort and TONS more people will be rewarded for your efforts.
Windows developers know how to write code for it.
Do they? Windows developers are going to be coding to GTK's and GNOME's interfaces? That's news to me. As far as I know, what this really means is that Windows C# programmers will be able to code C# on unix. Last I heard, Windows C and C++ programmers already know how to code C and C++ on unix. Please, tell me again where this magic bean grows from...
Lets make it easy to bring developers from the Windows world into our platform.
I must of fallen to sleep or something because I don't see how this has suddenly changed. Anyone?
Training materials, tutorials, documentation, tips and tricks are already available in large quantities, lets leverage this.
I seriously question this. Seems to me, that would be true as long as the programmer is really using C# and the underlying CIL implementation is the same. But, you're telling me that you're developing your own CIL and your own C# implementation so I doubt this will be true any more than it is today for any other given language and platform combination. More magic beans. Mmmm....I smell fresh brew magic coming my way...
Sorry folks, I've gone on long enough...I'm simply tired of typing. Obviously I don't see anything that he's stating other than there's a whole bunch of magic in this technology that no one has ever seen before. Furthermore, I think he helps make a wonderful argument that GNOME needs someone else at the helm. And if he's saying that he's not at the helm (I think he tried to say that too), then GNOME very badly needs someone which is not him.
I'll tell you right now that I'm completely ignorant of the implementation that's being used, however, as was often pointed out, FTP is being used as the transport and not the means to file management. I'm guessing this means they move the files around via FTP (from system to system) and then work with the copies (the newly FTP'd files) against the actual repository working set.
That being the case, I assume that all common file access is serialized and handled internally and that FTP is nothing more than a mode of transport.
MS VSS also uses a database (Jet based) and I can tell you, this can also lead to serious troubles. I can't even begin to tell you the number of files that it lost. Since the data is stored in a database, manual recovery is impossible unless you send the database to the vender, which we did on a regular basis. The worse thing was, often even they were unable to recover specific revisions of files and in many cases, whole files were completely lots.
What does this message mean? Well, VSS should never be used for serious, large scale development. VSS should never be used for remote/distributed development. Using a database for CM sounds wonderful, however, you need to be very picky about the backend that is being used. If the product is question is tied to a vendor's in house database format, find out what business they are in. If they truely did develop it in house, are they in the database business or the RC business? If they are in the later and did develope it in house, you should look elsewhere. I can't stress this enough. If you are using a backend database, ask you self, would you run your accounting/payroll on that database? If the answer is no, don't use that product for anything significant. In fact, don't use it all.
Just random ramblings follows here.
PVCS - Okay tool. Command line tools stink. VERY slow system, especially if you are in a distributed or heterogeneous environment. Reporting is neat and powerful but the slow and ackward GUI/command line tools just make it too painful for every day use.
StarTeam - Neat tool. Never used it for long term development. Speed was okay. Was weary of it somewhat because, IIRC, it used it's own database format. Overall, seemed like a good robust Microsoft only tool but take that with a grain of salt.
MSVSS- Horrible tool. Slow. Buggy. Destroys data. Unrealiable. Unusable in a distributed environment. I curse the day I'm forced to use those worthless product again.
ClearCase - Powerful tool. Found it to be somewhat odd but very flexable. Limited experience with it. Take this with a grain of salt.
MKS Souce Integrity - Evaluated this a long time but it seemed likea pretty good tool at the time. I seem to remember there were some caveots, however, I don't remember what they were. Again, take this with a grain of salt. Worth a look if you in the market and have time to evaluate.
While I've used many other tools, in addition to the ones above, I find that I keep coming back to CVS. Why? It's simple. Highly available. Crossplatform. Manual recovery with a high probability of sucess is possible. Supports distributed development well (better than most). While there certainly are some things that I would like to see improved in CVS (it's certainly not an end-all, do-all tool) I find that for the vast majority of projects, it fits good enough and is free. For those that are less command line inclined, GUIs for most every platform are readily available. Simply put, it works.
...in the situation that I've seen before, which sounds much like what you're describing, it was simply turned around that they owed a significant custom programming and consulting fee with out source ownership rights.
The customer in question soon saw the insanity of what they were doing and realized that it had backfired. Soon enough it was back to business are normal. In this particular case, as it turned out, the customer dearly liked the software and was hoping to leverage this situation to achieve better rates (discounts) on their software purchase.
OF Course it will. If there is anything that can be said in economics about any technology, it always operates at a 'discounted future.' Meaning that price will drop, and availability will increase. This is a given, unless free markets are not at play.
Funny you should say that. Since most cable and/or phone companies have a legal monopoly in many cities, free market is often not at play. Until the FCC gets off it's butt and requires that they compete and allow the free market system to work, people will continue to be screwed, receive bad service, and feel free to charge you whatever rates they see fit while limiting their rollouts.
My understanding and one of the common grips about QNX for the desktop is that QNX is POSIX-like and not UNIX-like. Remember, POSIX is not UNIX. Small yet distinct difference. Perhaps this has changed from years back but I know that used to be a very common misunderstanding and complaint once someone tried it out as a desktop system.
You bring up a good point. These patches originate to satisfy soft-realtime issues. As is often the case, many users simply want a fast response in their application and GUI in general. While saying that LL may be a magic bullet, might also the O(1) scheduler place some light on this by allowing those that simply want to have a "snappy" interface to get what they want? After all, do we really care is the interface is "snappy" 90% of the time and 10% not when under a load in their worse case latency situations? I personally would take that as I feel that the lower overhead and higher scalability gained by the scheduler more than makes up for it. At that point in time, doesn't addressing the last 10% of the high latency code by optimizing it seem more of an obtainable goal?
This isn't to say that these patches don't have value, clearly they do, however, I'm trying to point out that it seems there are really two camps. Those that *need* LL for soft-realtime and those that *want* a LL-like environment so they have click a button more timely. Of course, the extra plus with the scheduler is that it should scale better than the existing schedule and is very SMP friendly. Seems like this is where the average user should be looking.
It's a catch 22. You can plan all you want and have an estimate that is within, say, +-5%. The problem is, people want to know how long your estimate is going to take. Well, based on what I just told you, how long will it take to do the estimate? Exactly. But this doesn't stop people from thinking like that. Now, you're back to ball park guessing. When was the last time that someone wanted to pay you to estimate your estimate? Plus, people get upset when all they have is paper to show for their money. For some reason, if a software engineer shows you his design on paper, it has no value. On the other hand, if he shows you prototype code or a proof of concept, they feel like things are moving ahead. The problem is, if you design it right the first time, it will more than likely be a strong enough design to be able to evolve into anything that's needed. If it's kludged together, it sure does show, in money and time, now and later.
Because the guy at the repair shop can give you an estimate pretty much on the spot, many people expect the same to happen with everything else. Buildings would no doubt be the same way, EXCEPT, management won't tolorate this because of the liability issues. If management would grow up supported their people, and of course, stop pulling numbers out their butt, estimates in the software world might actually mean something. Until management fixes the problems that THEY created, they need to just shut their hole and write the check because it's THEIR screwup more often than not that they're paying for.
Re:Ok, so HURD is a microkernal os...
on
Hurd: H2 CD Images
·
· Score: 1
Actually, NT's kernel was never a true microkernel. Since microkernels were the rage of OS design back then, they hyped it as such. Remember, NT's kernel is also a fully OO-kernel too! Don't hear much about that any more. Turns out, they considered everything to be an object. You used an int, well, you used your object for today! According to their definition at the time, Linux *almost* qualifies as a microkernel and, by the way, did you know that Linux is an OO-kernel too?;)
Please don't get caught up in Microsoft's marketing which was total BS at the time. The NT kernel, _at the time_, had SOME attributes of a microkernel, some attributes of a monolithic kernel, some attributes of message passing kernel and some attributes of a functional design. You may recall that there was much stired up because most people that read the OS design papers agreed that it was a monolithic design while staunch microkernel (and VMS) advocates wanted it to be read as a microkernel design. Simply best to call it a hybrid kernel at the time.
Call it what you like, I think it's pretty well understood that it's a monolithic kernel which is and never has been object orientated.
FYI, England has laws which DeBeers is breaking there too, however, England prefers not to do anything about it. England is an internation hub for DeBeers' diamond trade.
I also believe IE was a failure with Microsoft as well, though people don't realize it. Now that IE is free MS makes no money on it, and does not, IMO, know how either. The result of this action is that Microsoft is stuck developing the worlds most popular web browser for free with no way to recoup development costs.
I'm always amazed when I read things like this. Nothing could be farther from the truth. Simply put, MS is no longer charging an EXTRA fee for IE, however, they ARE CHARGING FOR IT!!!!!! Besides, think about it this way, where would Microsoft's Internet plan be if only 20% of their customers purchased IE for use. No where. This is no different than buying your new Car which comes with free oil changes. It's not free. It's simply built into the cost. This is why it's so important for them to bundle it with the OS, so that it truely becomes an intergrated OS development cost....which at this point, it is. Of course, the obvious extention to this is, nothing from Microsoft is for free; it's always like that first hit of crack...you'll be forced to keep coming back at any price they name. Forced? Of course, because they are the only dealer in town.
Furthermore, in places where they want a Unix solution but are forced to go with Microsoft because the CEO has to have a shared calendar, Any server can now fill the roll. The CEO can use Outlook and the techies can use Ev.
Please, enlighten me - what servers other that Exchange work with Outlook shared calendaring?
I guess I should clarify this. Shared calendars are nothing more than messages being pushed to all people that it pertains to. That being said, as long as ANY client supports these messages, they can exist in a shared environment. Simply put, Exchange, for the most part, DOES NOT *DO* SHARED CALEDARING! Yes, it has support FOR it, but that support is pretty much limited to STORING and MANIPULATING the messages which contain the event in question. Didn't you know that you can envite people to meetings whos accounts don't exist on an Exchange Server??? Basically, Exchange Server allows for delegate permissions, asynchronous event notification and free/busy information. All of these items have free and/or open message specifications and protocols which are equivlent. Furthermore, even with Outlook, you can implement free/busy information WITHOUT THE NEED FOR AN EXCHANGE SERVER. Simply put, Outlook does 99% of all of collaborative work that people rush to give credit to Exchange Server for.
Go figure!
So, I guess the REAL answer to your question is, what CLIENTS support shared calendars?? The answer is, any that support iCal, vCard, and LDAP. Any client which fully support these is a canidate to replace Outlook as a collaborative client.
Except that the calendar information is actually stored as messages within the Exchange repository. Don't believe me, visit SlipStick (I think that's right) which has lots of tools and information to learn more about it. That being said, MS just tries to limit (in Exchange) the access paths (thusly the clients) which can retrieve this information. That is why it is all undocumented, nonetheless, again, Outlook is doing the magic...NOT Exchange.
Basically, Exchange Server is allowing for triggered events (non-polling) and some hooks to attach scripts and code to them.
IMAP doesn't cover are calendar/meeting, address-book, public folders, server-side inbox rules, poll-less message receipt, dynamic header download (as you scroll), etc...
You're right. IMAP doesn't provide for that as it's a transport layer! The messages that get transported (message formats) allow for that, save the address books, which LDAP happily covers. Server side rules. Yawn. Hardly required for collaborative tools to work and really out side the scope of what we are talking about. Dynamic header download? If I recall, IMAP allows for this. You simply indicate the range of headers that you are interested in. This can all be done without Outlook.
As usual, people seem to confuse implementation with technical boundaries. Simply put, pretty much EVERYTHING that people want for a shared/collaborative experience can be implemented using standard and open protocols and message formats.
The Open Office is also interested in this. Still don't believe me? Go visit them and you'll find that they are exploring the same road that I did a long time ago. Outlook does pretty much all of the work that people give credit to Exchange Server. I have no idea why this is so hard to accept, but let me assure you, Outlook does all (99%) of the work, including making the messages and/or manipulating the attributes on a message to give to Exchange Server to STORE. Exchange Server does very little aside from asynchronous event notification and storing of the MESSAGES that contain information on meetings and scheduled events.
Well, once you learn more about what Outlook and Exchange REALLY does, you'll learn that you don't have the foggiest idea what you're talking about. Outlook does 99% of all of the collaborative magic that people think Exchange Server is doing. If you bother to check you'll find that Exchange Server acts as nothing more than a data repository and that Outlook is actually doing most of it!
Don't believe me, join the ranks that know what they are talking about and spend a couple months learning how and what Outlook/Exchange does but reading up on sites about MAPI, Exchange Connectors, and various other tidbits which cover in detail how these things happen. In a nut shell, you are obviously not qualified to comment.
You'll need to turn on IMAP or POP4 access on your Exchange Server. Since Exchange Server really isn't doing anything, this client should be on par pretty quickly. What does that mean? Well, Outlook is really doing 99% all of the work that people seem to attribute to Exchange Server. That being the case, once an open client supports 99% of everything that Outlook does, it greatly obsoletes the need for an Exchange Server for, I'd guess, 80% of Microsoft's installations. Furthermore, in places where they want a Unix solution but are forced to go with Microsoft because the CEO has to have a shared calendar, Any server can now fill the roll. The CEO can use Outlook and the techies can use Ev. That's not to say that 80% of the Exchange Server installations will dump it, rather, there simply won't be a requirement for it to achieve the same results.
The first thougt I had about this device is for military and commercial air transport. Many planes have an extra, though much smaller, turbine to generate electricity. What if these were used on the primary turbines (HUGH temp delta here...very hot exhaust...much cooler external temp) to generate electricity. What about for emergencies? Some fighters have little alternators that pop up from the side of the plane with a prop which allows for emergency electricity. As long as the turbine is still attached, wouldn't this make a good emergency source of power? Same with helecopters? I know Apaches have, what, two 1200Hp turbines. I know there's a lot of heat there with a huge fan right over head to help cool it. Seems like these would all be prime targets for first serious applications.
Slashdot Mirror
Hi Josh.
I someone wanted to become active in contributing to this project, who would we need to contact? Is there a primary contact for each sub-project?
Someone please MOD this up!
:P~
Thanks for the info. I didn't know that.
What a karma whore...
Don't take this the wrong way but that is seemingly exactly an ideal project for which MySQL was made for. Data access appears to be primarily read-only with none of it being critical. Worse case, if the database becomes corrupt, you simply restore the whole thing from back up. Since the data doesn't appear (based on description) to be changing rapidly (if at all or perhaps backend updates only), issue such as online back or high availability is likely not to be an issue in the least. If they were, they'd probably be using that Oracle license.
Always remember that table statistics are used for approximate best guesses for inputs to the query optimizer. It is not uncommon or unheard of to actually see somes types of queries run slower after table statistics have been updated. I've seen this on Oracle, Sybase and SQL Server. I doubt that this is an issue unique to those RDBMS since the conceptual implementations and basis for algorithms tend to all be more or less the same.
Again, I plead ignorance about the implementation details. Simply put, I find it hard to believe that such a thing is an issue. Unless you have specific instances to cite rather than broad and general speculations about a specific implementation which neither of us seem to know anything about, your comment is seemingly without merit.
Agreed, a reliable SM system does require some sort of locking mechanism, but this hardly requires the transport to support this. Again, I could talk until I'm blue in the face about guesses as to why this isn't a concern however it would simply be a guess...as is your concern.
Simple question. Did it say that they use standard FTP daemons or that they use the FTP protocol? If they are using a standard server then clearly you are going to be limited by the constraints of that server's feature set, however, if they are simply using the FTP protocol, then your comments are completely unfounded. Either way, I can easily imagine mechanisms which avoid your issue all together, so as far as I'm concerned, it's a moot issue.
In a nut shell, I can't understand how your comment was mod'ed +1.
First, let me say that I use Gnome for my desktop and have used GTK+ for sizable projects. I've even developed smaller GNOME applications and found the various API's horrible. I can't stress enough that I'm not trying to cook someone here for the sake of cooking. I think the only point he makes here is that GNOME is without a solid technology direction and has suffered dearly for it for a very long time. In fact, he as much as points this out. So, call me a troll if you like but I fail to see how Mono isn't anything other than a new tech headline. Please read below if you care to follow his assumptions while he explains pretty much nothing.
The CIL and the promise of language independence
This is what CORBA promised more or less. Please correct me if I'm wrong, but didn't Gnome start out using CORBA and decided that it needed different technologies later in the cycle?
Are there not already language bindings for C, C++, Python, Perl and I'm sure several others? So tell me again why we need an interpretted wanna-be CORBA in the mix?
This technology allows programming languages to be considered on the basis of how they will perform for a given task, and not based on the runtime libraries that you will depend. Any software engineer should read this article:
Generally speaking, good engineers already do this. The choice of yet another tool somehow doesn't make this happen, though, choice can be a good thing. Adding a slow runtime is not going to make the awesomely optimized FORTAN libs suddenly appear and become compatible with various CIL implementations. In fact, really all you can say is that when you use this technology [CIL implementations], the language of choice will no longer effect performance rather it will be forced back onto the developers to optimize for a given language; that is, language specific CIL tuning tricks. On the other hand, all of the languages which use this are going to have a negative performance impact so it sounds like programmers will have even more choice (seemingly pointless). Let's see, I can pick C or C++ for performance or I can pick C/C++/C# [CIL implementations] which performs an order of magnitude slower. Hmmm. Hard choice. Tell me again why I should care about CIL, Mono and C#??
GNOME had always tried to have a good support for multiple programming languages.
No it hasn't. Save only for the CORBA efforts, GNOME is very C biased. One of the common complaints coming from the C++ KDE camp. The more correct statement would be, "multiple programming languages have always tried to support GNOME." These efforts have inflicted various levels of pain on their bindings implementors.
They have incorporated many ideas from Java, and they have extended it to address new needs that developers had. They took where Java left off.
What does that mean? Sounds like they are re-implementing Java. Why? Why don't you just further improve Java. I'll make it known here, I've never beena Java fan but this just doesn't make sense to me. It only makes sense to Microsoft because they badly need to de-crown Java. Aside from Microsoft, I don't see how this helps anyone. By the way, what are these "new needs that developers had", that existing technologies can't address? Do we really have to move to a VM to address these needs?? Somehow this seems like we're taking several steps backward. Anyone?
Libraries have been built by disconnected groups (PNG, JPEG, Gtk+, Xml, Bonobo, CORBA spec apis, etc) and the end result is that a developer eventually has to learn more than he wanted to in the course of developing a large application.
Might this have more to do with the fact that GNOME has been wondering without direction for a very long time and no one in the GNOME camp has been willing to settle and agree on a single API nor the technology behind these APIs? Does it have to be the programmer's fault? Can't it be that the API's provided have just sucked? Can't it be that the API's have changed so fast and often that programmers wonder what they are doing trying to implement a large application via GNOME? Can't this mean that the implementations behind the API's have been less than wonderful and seemingly change daily? Does it have to be because programmers don't want to learn? Seems to me, if programmers didn't want to learn, they wouldn't be trying to develope large applications in a highly dynamic environment (from an API perspective). Wouldn't a static API help address this? Won't simply adding yet another API compound this issue even further?
There is a point in your life when you realize that you have written enough destructors, and have spent enough time tracking down a memory leak, and you have spend enough time tracking down memory corruption, and you have spent enough time using low-level insecure functions, and you have implemented way too many linked lists [1]
Doesn't this really reflect the choice of underpinning APIs and implementations behind the APIs as much as the language. It's funny, I've developed very large applications (C/C++) before and never had nearly as many issues as one does when trying to use the GNOME/GTK technologies. Might it be that you've been chasing the wrong end of the technology spectrum? Might it be that you should of been looking to replace GTK and the billion other obtuse libraries that are the foundation of GNOME with better, faster, stronger technologies? Might is be that the number of memory leaks and associated debugging issues have something to do with design skills and/or coding habits? In not in whole, in part? Some part? Maybe a little? If you have even a small problem which is compounded over and over in various suite of libs that is GNOME, might this actually result in a large problem manifesting it self as obtuse APIs which lend them self to these issues?
Evolution took us two years to develop and at its peak had 17 engineers working on the project. I want to be able to deliver four times as many free software applications with the same resources, and I believe that this is achievable with these new technologies.
Wow! This really is magic technology1 It's going to 4x the level of productivity over any other tool, toolkit, and language. Wow! Does it come with a bridge too? I can't wait.
Even C++ was invented at ATT.
Yes, you're right, however, it was written by people who wanted to look at solving real problems with a different approach while leveraging the large C programmer base. It was need driven. The same can not be said for C# and CIL. Both of these are being driven my Microsoft to side step Sun and Java. The motive is as important as anything else, especially when we are talking about Microsoft. If, according to you, it's pretty much Java with some icing, why not go the shortest and best path for everyone and help improve Java? Go ahead, make the icing for Java. Then, you'll have everything you're asking for with a whole lot less effort and TONS more people will be rewarded for your efforts.
Windows developers know how to write code for it.
Do they? Windows developers are going to be coding to GTK's and GNOME's interfaces? That's news to me. As far as I know, what this really means is that Windows C# programmers will be able to code C# on unix. Last I heard, Windows C and C++ programmers already know how to code C and C++ on unix. Please, tell me again where this magic bean grows from...
Lets make it easy to bring developers from the Windows world into our platform.
I must of fallen to sleep or something because I don't see how this has suddenly changed. Anyone?
Training materials, tutorials, documentation, tips and tricks are already available in large quantities, lets leverage this.
I seriously question this. Seems to me, that would be true as long as the programmer is really using C# and the underlying CIL implementation is the same. But, you're telling me that you're developing your own CIL and your own C# implementation so I doubt this will be true any more than it is today for any other given language and platform combination. More magic beans. Mmmm....I smell fresh brew magic coming my way...
Sorry folks, I've gone on long enough...I'm simply tired of typing. Obviously I don't see anything that he's stating other than there's a whole bunch of magic in this technology that no one has ever seen before. Furthermore, I think he helps make a wonderful argument that GNOME needs someone else at the helm. And if he's saying that he's not at the helm (I think he tried to say that too), then GNOME very badly needs someone which is not him.
Greg
I'll tell you right now that I'm completely ignorant of the implementation that's being used, however, as was often pointed out, FTP is being used as the transport and not the means to file management. I'm guessing this means they move the files around via FTP (from system to system) and then work with the copies (the newly FTP'd files) against the actual repository working set.
That being the case, I assume that all common file access is serialized and handled internally and that FTP is nothing more than a mode of transport.
MS VSS also uses a database (Jet based) and I can tell you, this can also lead to serious troubles. I can't even begin to tell you the number of files that it lost. Since the data is stored in a database, manual recovery is impossible unless you send the database to the vender, which we did on a regular basis. The worse thing was, often even they were unable to recover specific revisions of files and in many cases, whole files were completely lots.
What does this message mean? Well, VSS should never be used for serious, large scale development. VSS should never be used for remote/distributed development. Using a database for CM sounds wonderful, however, you need to be very picky about the backend that is being used. If the product is question is tied to a vendor's in house database format, find out what business they are in. If they truely did develop it in house, are they in the database business or the RC business? If they are in the later and did develope it in house, you should look elsewhere. I can't stress this enough. If you are using a backend database, ask you self, would you run your accounting/payroll on that database? If the answer is no, don't use that product for anything significant. In fact, don't use it all.
Just random ramblings follows here.
PVCS - Okay tool. Command line tools stink. VERY slow system, especially if you are in a distributed or heterogeneous environment. Reporting is neat and powerful but the slow and ackward GUI/command line tools just make it too painful for every day use.
StarTeam - Neat tool. Never used it for long term development. Speed was okay. Was weary of it somewhat because, IIRC, it used it's own database format. Overall, seemed like a good robust Microsoft only tool but take that with a grain of salt.
MSVSS- Horrible tool. Slow. Buggy. Destroys data. Unrealiable. Unusable in a distributed environment. I curse the day I'm forced to use those worthless product again.
ClearCase - Powerful tool. Found it to be somewhat odd but very flexable. Limited experience with it. Take this with a grain of salt.
MKS Souce Integrity - Evaluated this a long time but it seemed likea pretty good tool at the time. I seem to remember there were some caveots, however, I don't remember what they were. Again, take this with a grain of salt. Worth a look if you in the market and have time to evaluate.
While I've used many other tools, in addition to the ones above, I find that I keep coming back to CVS. Why? It's simple. Highly available. Crossplatform. Manual recovery with a high probability of sucess is possible. Supports distributed development well (better than most). While there certainly are some things that I would like to see improved in CVS (it's certainly not an end-all, do-all tool) I find that for the vast majority of projects, it fits good enough and is free. For those that are less command line inclined, GUIs for most every platform are readily available. Simply put, it works.
...in the situation that I've seen before, which sounds much like what you're describing, it was simply turned around that they owed a significant custom programming and consulting fee with out source ownership rights.
The customer in question soon saw the insanity of what they were doing and realized that it had backfired. Soon enough it was back to business are normal. In this particular case, as it turned out, the customer dearly liked the software and was hoping to leverage this situation to achieve better rates (discounts) on their software purchase.
OF Course it will. If there is anything that can be said in economics about any technology, it always operates at a 'discounted future.' Meaning that price will drop, and availability will increase. This is a given, unless free markets are not at play.
Funny you should say that. Since most cable and/or phone companies have a legal monopoly in many cities, free market is often not at play. Until the FCC gets off it's butt and requires that they compete and allow the free market system to work, people will continue to be screwed, receive bad service, and feel free to charge you whatever rates they see fit while limiting their rollouts.
I _really_ want to see software distributors start to offer packages looking like this: gnome-core-2.0.386.lsb.rpm
Man, I agree with that!!!
Someone mod his comment up!!!
That's pretty cool! I didn't know that!
This for real???
My understanding and one of the common grips about QNX for the desktop is that QNX is POSIX-like and not UNIX-like. Remember, POSIX is not UNIX. Small yet distinct difference. Perhaps this has changed from years back but I know that used to be a very common misunderstanding and complaint once someone tried it out as a desktop system.
You bring up a good point. These patches originate to satisfy soft-realtime issues. As is often the case, many users simply want a fast response in their application and GUI in general. While saying that LL may be a magic bullet, might also the O(1) scheduler place some light on this by allowing those that simply want to have a "snappy" interface to get what they want? After all, do we really care is the interface is "snappy" 90% of the time and 10% not when under a load in their worse case latency situations? I personally would take that as I feel that the lower overhead and higher scalability gained by the scheduler more than makes up for it. At that point in time, doesn't addressing the last 10% of the high latency code by optimizing it seem more of an obtainable goal?
This isn't to say that these patches don't have value, clearly they do, however, I'm trying to point out that it seems there are really two camps. Those that *need* LL for soft-realtime and those that *want* a LL-like environment so they have click a button more timely. Of course, the extra plus with the scheduler is that it should scale better than the existing schedule and is very SMP friendly. Seems like this is where the average user should be looking.
Am I missing something?
Greg
It's a catch 22. You can plan all you want and have an estimate that is within, say, +-5%. The problem is, people want to know how long your estimate is going to take. Well, based on what I just told you, how long will it take to do the estimate? Exactly. But this doesn't stop people from thinking like that. Now, you're back to ball park guessing. When was the last time that someone wanted to pay you to estimate your estimate? Plus, people get upset when all they have is paper to show for their money. For some reason, if a software engineer shows you his design on paper, it has no value. On the other hand, if he shows you prototype code or a proof of concept, they feel like things are moving ahead. The problem is, if you design it right the first time, it will more than likely be a strong enough design to be able to evolve into anything that's needed. If it's kludged together, it sure does show, in money and time, now and later.
Because the guy at the repair shop can give you an estimate pretty much on the spot, many people expect the same to happen with everything else. Buildings would no doubt be the same way, EXCEPT, management won't tolorate this because of the liability issues. If management would grow up supported their people, and of course, stop pulling numbers out their butt, estimates in the software world might actually mean something. Until management fixes the problems that THEY created, they need to just shut their hole and write the check because it's THEIR screwup more often than not that they're paying for.
Actually, NT's kernel was never a true microkernel. Since microkernels were the rage of OS design back then, they hyped it as such. Remember, NT's kernel is also a fully OO-kernel too! Don't hear much about that any more. Turns out, they considered everything to be an object. You used an int, well, you used your object for today! According to their definition at the time, Linux *almost* qualifies as a microkernel and, by the way, did you know that Linux is an OO-kernel too? ;)
Please don't get caught up in Microsoft's marketing which was total BS at the time. The NT kernel, _at the time_, had SOME attributes of a microkernel, some attributes of a monolithic kernel, some attributes of message passing kernel and some attributes of a functional design. You may recall that there was much stired up because most people that read the OS design papers agreed that it was a monolithic design while staunch microkernel (and VMS) advocates wanted it to be read as a microkernel design. Simply best to call it a hybrid kernel at the time.
Call it what you like, I think it's pretty well understood that it's a monolithic kernel which is and never has been object orientated.
FYI, England has laws which DeBeers is breaking there too, however, England prefers not to do anything about it. England is an internation hub for DeBeers' diamond trade.
If it's the critter that I think it is, there is a picture of one in "Backyard Flyer". This thing is smaller than your hand.
I also believe IE was a failure with Microsoft as well, though people don't realize it. Now that IE is free MS makes no money on it, and does not, IMO, know how either. The result of this action is that Microsoft is stuck developing the worlds most popular web browser for free with no way to recoup development costs.
I'm always amazed when I read things like this. Nothing could be farther from the truth. Simply put, MS is no longer charging an EXTRA fee for IE, however, they ARE CHARGING FOR IT!!!!!! Besides, think about it this way, where would Microsoft's Internet plan be if only 20% of their customers purchased IE for use. No where. This is no different than buying your new Car which comes with free oil changes. It's not free. It's simply built into the cost. This is why it's so important for them to bundle it with the OS, so that it truely becomes an intergrated OS development cost....which at this point, it is. Of course, the obvious extention to this is, nothing from Microsoft is for free; it's always like that first hit of crack...you'll be forced to keep coming back at any price they name. Forced? Of course, because they are the only dealer in town.
Furthermore, in places where they want a Unix solution but are forced to go with Microsoft because the CEO has to have a shared calendar, Any server can now fill the roll. The CEO can use Outlook and the techies can use Ev.
Please, enlighten me - what servers other that Exchange work with Outlook shared calendaring?
I guess I should clarify this. Shared calendars are nothing more than messages being pushed to all people that it pertains to. That being said, as long as ANY client supports these messages, they can exist in a shared environment. Simply put, Exchange, for the most part, DOES NOT *DO* SHARED CALEDARING! Yes, it has support FOR it, but that support is pretty much limited to STORING and MANIPULATING the messages which contain the event in question. Didn't you know that you can envite people to meetings whos accounts don't exist on an Exchange Server??? Basically, Exchange Server allows for delegate permissions, asynchronous event notification and free/busy information. All of these items have free and/or open message specifications and protocols which are equivlent. Furthermore, even with Outlook, you can implement free/busy information WITHOUT THE NEED FOR AN EXCHANGE SERVER. Simply put, Outlook does 99% of all of collaborative work that people rush to give credit to Exchange Server for.
Go figure!
So, I guess the REAL answer to your question is, what CLIENTS support shared calendars?? The answer is, any that support iCal, vCard, and LDAP. Any client which fully support these is a canidate to replace Outlook as a collaborative client.
Except that the calendar information is actually stored as messages within the Exchange repository. Don't believe me, visit SlipStick (I think that's right) which has lots of tools and information to learn more about it. That being said, MS just tries to limit (in Exchange) the access paths (thusly the clients) which can retrieve this information. That is why it is all undocumented, nonetheless, again, Outlook is doing the magic...NOT Exchange.
Basically, Exchange Server is allowing for triggered events (non-polling) and some hooks to attach scripts and code to them.
IMAP doesn't cover are calendar/meeting, address-book, public folders, server-side inbox rules, poll-less message receipt, dynamic header download (as you scroll), etc...
You're right. IMAP doesn't provide for that as it's a transport layer! The messages that get transported (message formats) allow for that, save the address books, which LDAP happily covers. Server side rules. Yawn. Hardly required for collaborative tools to work and really out side the scope of what we are talking about. Dynamic header download? If I recall, IMAP allows for this. You simply indicate the range of headers that you are interested in. This can all be done without Outlook.
As usual, people seem to confuse implementation with technical boundaries. Simply put, pretty much EVERYTHING that people want for a shared/collaborative experience can be implemented using standard and open protocols and message formats.
The Open Office is also interested in this. Still don't believe me? Go visit them and you'll find that they are exploring the same road that I did a long time ago. Outlook does pretty much all of the work that people give credit to Exchange Server. I have no idea why this is so hard to accept, but let me assure you, Outlook does all (99%) of the work, including making the messages and/or manipulating the attributes on a message to give to Exchange Server to STORE. Exchange Server does very little aside from asynchronous event notification and storing of the MESSAGES that contain information on meetings and scheduled events.
Well, once you learn more about what Outlook and Exchange REALLY does, you'll learn that you don't have the foggiest idea what you're talking about. Outlook does 99% of all of the collaborative magic that people think Exchange Server is doing. If you bother to check you'll find that Exchange Server acts as nothing more than a data repository and that Outlook is actually doing most of it!
Don't believe me, join the ranks that know what they are talking about and spend a couple months learning how and what Outlook/Exchange does but reading up on sites about MAPI, Exchange Connectors, and various other tidbits which cover in detail how these things happen. In a nut shell, you are obviously not qualified to comment.
Hheheh....you've been sucked into MS's web! Outlook does it...NOT Exchange Server!!!! Exchange Server simply acts as a mail repository. Imagine that!
HEHEHE!
You'll need to turn on IMAP or POP4 access on your Exchange Server. Since Exchange Server really isn't doing anything, this client should be on par pretty quickly. What does that mean? Well, Outlook is really doing 99% all of the work that people seem to attribute to Exchange Server. That being the case, once an open client supports 99% of everything that Outlook does, it greatly obsoletes the need for an Exchange Server for, I'd guess, 80% of Microsoft's installations. Furthermore, in places where they want a Unix solution but are forced to go with Microsoft because the CEO has to have a shared calendar, Any server can now fill the roll. The CEO can use Outlook and the techies can use Ev. That's not to say that 80% of the Exchange Server installations will dump it, rather, there simply won't be a requirement for it to achieve the same results.
The first thougt I had about this device is for military and commercial air transport. Many planes have an extra, though much smaller, turbine to generate electricity. What if these were used on the primary turbines (HUGH temp delta here...very hot exhaust...much cooler external temp) to generate electricity. What about for emergencies? Some fighters have little alternators that pop up from the side of the plane with a prop which allows for emergency electricity. As long as the turbine is still attached, wouldn't this make a good emergency source of power? Same with helecopters? I know Apaches have, what, two 1200Hp turbines. I know there's a lot of heat there with a huge fan right over head to help cool it. Seems like these would all be prime targets for first serious applications.