.NET is still a vague concept to me, but one of the main guys behind it said that C# was analagous to Java the language, while.NET was analagous to Java the platform. I took that to mean the JVM and things like the EJB and Servelet standards.
Developer View: .NET is the next generation of Microsoft's component technologies (COM, COM+, DCOM) which incorporates lessons learned from Java. COM is a technology that allows you to interact with components written in different languages transparently and is descended from OLE (Object Linking and Embedding which is the technology that was developed to allow being able to drag an Excel spreadsheet into a Word document) and . The languages that support COM are the Visual Studio languages as well as Object Pascal (Delphi). COM has its own binary format and while works almost transparently from Javascript, VB, and VBScript is a bitch to work with from C++. DCOM is the same as COM but it adds being able to do RPC (remote method invokation for the Java heads) from components irrespective of what language they are written in, kinda like CORBA without the ORBs.
.NET simplifies this by having a Common Language Runtime which is analogous to the Java JVM. COMable languages simply compile to the CLR format instead of to assembly code or a weird binary format. So this should lead to the best of both worlds by giving you all the functionality you have come to expect from the Java platform with the added benefit of using languages other than Java (C++, C#, VB, Javascript, VBScript, Perl and a few others) and transparently interact with objects written in these languages. Because all.NET languages have access to the CLR they can utilize it to extend themselves, e.g. Visual C++ has "managed extensions" that allows for garbage collection via the CLR.
The major goal is then to use this technology to build XML based web services.
They've
come far and fast by having the right kind of smarts at the right time and place. That they didn't know they were living in a speculative bubble
and far beyond their means
I refuse to believe that anybody smart (heck, anyone with an ounce of intelligence) couldn't tell that LEASING three cars for his girlfriend was a stupid idea when he was a salaried employee for a company that was extremely overvalued (they all were) and not a rich millionairre with cash in the bank.
6. The world is not object oriented. Even if oo is a usefull tool, it is no silver bullet.
Which makes more sense when writing an application using an object oriented programming language to develop an application? Using a database that is consistent with the programming paradigm and performs database operations transparently or one that requires the developer to go through additional hoops to get data, is generally slower, and involves writing more code?
7. RDBMS are proven technology and rather well standardised, OODBMS aren't. Currently there is a proposal for a standard (java data objects), but even that only addresses one plattform.
Not only is there a standard but the ODMG standard is on version 3, JDO is merely a Java standard. Please know the facts before flaming.
Hi, thanks for the responses, I didn't think anyone would be done reading it so quickly.:)
Complexity. These systems are much more difficult to design than RDBMS. The application must be designed first, then the data structures must accomodate that. This kind of design is very expensive.
Aren't you supposed to design an application before implemnting it in any way including putting data in a DB? I've worked at two companies and had a ton of projects in school and none involved implemnting the database
before the application was designed.
RDBMSs are generic. Since an OO system is designed for a specific application, it's difficult to use that system for anything else. A well-designed, properly normalized RDBMS can be used for many different applications. When a DB is going to fill many terabytes, you don't want to have multiple copies of it for each distinct reporting application.
This is simply hogwash. RDBMSs are by their nature non-generic espoecially when one adds foreign keys and constaints to a system which are necessary for any decent sized application. On the other hand the entire point of object oriented programming is creating generic reusable components. With the ability to use inheritance and polymorphism in an ODBMS I see no reason why you believe an RDBMS is more generic.
Schema changes. As mentioned in the article, schema changes are a nightmare with an OO system. In a relational system, some changes can be made with no impact on existing applications. Others are relatively uncomplicated compared to similar OO changes.
...and in an OO system some changes can be made without no effects on the existing applications. In the general case though an RDBMS is more flexible than an ODBMS.
Skills availability. Yes, the old management problem. Everyone knows SQL; nobody knows OO.
Learning OODBMS techniques is mainly learning how to use another API in your bject Oriented programming language of choice (well C++, Java or Smalltalk) versus learning SQL and relational database theory. If people could learn SQL which is completely unrelated to any other aspect of their programming experience then adding OODBMS techniques as a skillset would be trivial. Of course, if people don't realize that alternatives to RDBMSs exist then they won't learn these techniques. That is more important because management can't find people who have these skills if developers don't go out and learn these techniques.
It's just not worth it. Given the dramatically higher costs associated with designing and maintaining an OO system, most applications just don't need the incremental performance gains associated with it. Very specialized, very high performance systems would benefit, but smaller or more general systems would not.
Now I just realized you didn't read the article. People have measured gains in the range of ten to a thousandfold increase in performance, these are not incremental.
Secondly the primary benefit is that it means you have to write less code and don't have to worry about multiple paradigms at once when implementing an application.
Finally, where the heck are you getting this BS that designing an application with a single data model (i.e. one set of UML diagrams) is more expensive than designing one with 2 data models (i.e. an ER model for the DB, UML for the application).
No, the strength of free software is that it is free. By tying it into treaties and contracts with companies we lose the strength which makes it far superior to any closed-source equivalent. We all know corporations aren't to be trusted, and despite their current "nice guy" acts, both IBM and HP have in the past abused their positions within the industry for their own gains.
People like the above poster and Bruce Perens make me wonder exactly where the notion of an Open Source Community and the concept of "we" comes up in this discussion. Bruce Perens does not represent the Linux kernel hackers, the Apache Foundation, the *BSD coders nor even the people that hack Slashcode. So on exactly whose behalf is he signing treaties with and who will enforce his end of the bargain?
I've previously told Bruce on kuro5hin that companies have no incentive to give up their IP and in fact will probably lose out on the deal (OpenSSH vs. SSH is a good example) and I'm yet to see a good counter argument for that. Also the fact that he has nothing to back up his threats to them with is also not encouraging. Here's an excerpt my reply to his post on K5 about that.
Regarding what incentive the big companies have to negotiate with us regarding their patents, if they were not interested in negotiating with us, we'd have reason to re-evaluate our participation with them, wouldn't we?
What exactly does this mean? Contrary to what most people who read slashdot and K5 believe, there is no Open Source community in any cohesive sense of the word. I doubt that Linux kernel developers are going to stop accepting kernel patches from IBM because they refused to give up all their IP when Bruce Perens said so, neither do I see the Apache Software Foundation kicking off the IBM members.
Secondly due to the nature of the GPL and other Open Source licenses, these companies can continue to reap the benefits of Open Source software even without the gestures they've made to the community. Quite frankly, companies like IBM, HP, Apple and Sun have been under no obligation to support Open Source in the ways that they have already. Taking this for granted and assuming that we can demand more seems to me to be the height of folly. This slashdot post though sarcastic should bring home the point that I am trying to get across.
In talking about whether or not a company can make money with Free Software, we should remain aware that most companies are deploying Free Software in a cost-center (like IS support at a business or systems programming at a hardware vendor), and if they save money in that cost-center by distributing the work load over multiple companies rather than duplicating effort in each of them, it's as good as making the money elsewhere. It's that cost-savings that is funding most of the Linux jobs today, not profit.
Exactly, and the kind of companies that see IS/IT as a cost center and Open Source products as a way to bring down costs are typically not the kind of companies that will jeopardize future profits to help the Open Source cause. Most of these companies would jump on a cheaper closed source solution in a heartbeat and do not feel indebtedness to the Open Source cause to the level to which you suggest.
People who claim that the BSDL, which is from a older tradition of giving back to the community than the GPL, is not "Free Software" make me want to puke. The BSDL is "Free Software" even by RMS's definitions of the term "Free Software". Let's check and see if the BSDL conforms to the features RMS set out for free software:
The freedom to run the program, for any purpose (freedom 0). Check
The freedom to study how the program works, and adapt it to your needs
(freedom 1). Access to the source code is a precondition for this. Check
The freedom to redistribute copies so you can help your neighbor
(freedom 2). Check
The freedom to improve the program, and release your improvements
to the public, so that the whole community benefits.
(freedom 3). Access to the source code is a precondition for this. Check
Wow, looks like the BSDL is Free Software. Please repeat after me, The GPL is not the only Free Software license. Thanks for playing. Goodbye.
If you actually read the email, you see that they are awarding prizes and stuff for people that report requests for computers without OEM Windows installed because of a site license. Microsoft says that their site licenses do not cover new computers.
The email quoted was shown as an example and also shown to justify why they were doing it.
What MSFT is asking the OEMs to do is rat out anyone who requests a bid on PCs without asking for a quote on Windows being installed on all the machines. This is tantamount to claiming that all PCs should be running Windows or the purchasers are pirates. This then probably means that the purchaser should then expect a visit from the MSFT audit team.
It's an interesting ploy and seems reasonable when one considers that most people buying a large number of PCs would want an OS installed until one realizes that they may plan to just put Linux or *BSD on the boxes.
How the did the above post get modded up to +4 interesting?
Logging bugs, and giving them "severities", is well and good. It can help in the same way that any effective software development tool helps, by enhancing communication. The moral is that bug tracking is useful only in the context of a team that can, and wishes to, use it effectively.
Wrong. Software engineering practices like tracking the severity and priority of bugs are aimed at creating higher quality software. Instead of developers spending time fixing bugs that are unimportant or not as annoying to the user, they have a way of categorizing and fixing bugs on a scale of importance.
Using bug count and severity as a measure of "releasability", however, is the fallacy of feeble-minded managers, who are afraid to make a decision without a number to back it up.
Yet people like you will bitch that Microsoft shouldn't release software with known severe bugs. I guess if they didn't track bugs they would be able to say they didn't know that there were any severe bugs with a clear conscience.
Software development (as practiced in all but epsilon of cases) is simply not a measurable process. You will only waste your time trying to quantify it.
Software development can be measured based on a large number of metrics. The fact that most people refuse to use software engineering practices that have been known for decades doesn't mean that the process is "immeasurable" it simply means our industry is full of people who'd rather subscribe to the myth that programming is an art instead of trying to make it an engineering discipline.
Releasability can only be determined by the judgement of the team working on the release (which may include developers, testers, release managers, beta testers, partners, etc). That is not to say that you should not draw upon the bug database for evidence upon which to base your judgement. But it requires intelligent interpretation, not counting up some totals.
So if the members of the team come up with the rules for what makes a bug a certain severity and what marks a bug as a certain priority exactly why can they not base releasability on these metrics? Quite frankly, waiting until the software "feels right" before releasing it is probably the most ridiculuos thing I've ever heard. On the other hand saying "we won't release until all the bugs that cause core dumps/segfaults/BSODs are fixed (severity one)" or that "we won't ship until we fix the annoying UI issues (priority one or two)" are quite reasonable even from a common sense point of view.
Some people consider this a failing of the software development process. I think they are too quick to condemn. The customer doesn't (usually) judge software by its bug count.
Interestingly most users of Windows 98 I know judged the software on its bug count (i.e. how many crashes needing reboots per day or other ridiculuos problems per day)
Most software is judged by an overall feel: if the software is compelling, many deficiencies will be overlooked. Further, it is difficult to guess ahead of time (even with beta testing) which bugs will really bite people and impede their use of the software.
If beta testers don't give you a feel for a large number of the bugs that will bite people on the ass then there are flaws in your beta-testing process.
Given the many interacting factors that determine the success of software, release decisions are naturally more art than science.
People like you are the major problem with the software industry. Those that believe that even though there have been increasing strides in the field of sooftware engineering, we should all still practice software development like it is a black art handed down from master to apprentice in a scene reminescent of guilds of the middle ages.
I know, I haven't presented any hard evidence. I'm arguing from experience in both free and closed software projects, and appealing to common sense. Most free software is released "when it's ready", without any metrics. Ponder on whether this is a strength or a weakness. And remember that when someone gives you number, the burden is on him to show that the number means something.
Do you really think Mozilla, GNOME, KDE, Apache, the Linux kernel, OpenBSD, etc are shipping "stable" releases of software without keeping an eye on bug severities and priorities? They may choose to ignore them for one reason or the other but they are keeping track.
Will someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea? What is done wrong in Mach, and can it be fixed?
Inefficient kernel-user switching (i.e. system calls spend too much unecessary time in the kernel).
Inefficient address switching (i.e. the number of cache and TLB misses in the Mach microkernel is also absurdly large).
The performance of IPC operations and thread switching is subpar. (this is related to the above points).
It isn't optimized for specific hardware and instead has a Hardware Abstraction Layer which slows it down considerably.
The paper is a few years old so the Mach people may have tackled some of these problems by now.
If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel? Are any well-designed microkernels out there?
If there are, then what is it that repeatedly leads projects like xMach/HURD/OS X/mkLinux to embrace Mach as opposed to one of the competing microkernels?
The same reason most of us are using Java and C++ instead of SmallTalk, Lisp or Objective-C. Developer inertia and people falling to the more hyped and/or better sold technology.
and, btw, this is kind offtopic, but while we're VAGUELY near the subject: someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true? How does that work in terms of sharing the hardware? How do you go about doing this?
A microkernel can load different modules at runtime that may be OS emulation layers that mimic the behaviors of certain OSes even down to memory management and paging. Since you can theroetically load as many modules as you want, you can load various emulation layers and mimic several OSes at once. For instance OS X has a microkernel that loads modules to mimic BSD as well as old Apple APIs (Classic) as well as teh new stuff (Carbon). Here's a graphical look at how the MacOS X architecture.
Don't expect these changes anytime soon though. From recent ACCU meetings it seems that most of the C++ standard from 1997 still hasn't been implemented now let alone new libraries that are yet to be designed. The soonest I see any of Bjarne's ideas being usable by developers and standardized is 2005 if the rate of compiler and library development continues at the current rate.
Isn't this just doing stuff similar to what strong validators a là Entity Tags in HTTP requests and responses use for determining whether a page has been changed (i.e. is in the cache) or not?
The only difference I can see is that they generate an Etag like entity for tect highlighted by the user as well as the entire webpage. Doesn't seem worthy of a patent though.
True, but a) Prohibition didn't work, we tried it before and b) alcohol certainly has medical benefits if consumed in moderation. Drugs don't. I will admit that tobacco is evil however, but it is a necessary evil to many farmers.
Interesting arguments. You realize that the Prohibition is exactly like the War on Drugs with regards to the minor drugs like Ecstacy and Marijuana. Here are somearticles about the war on drugs.
Expenditure on substance increases because a.) demand for it is inelastic and b.) it becomes more scarce.
Violent gang wars over illicit profits.
People criminalized for activity that harmed no one but themselves.
Point me to some studies showing the medical benefits of drugs if you can. And not ones conducted by fronts for organisations like NORML which advocate making drugs available to everyone
I didn't argue that drugs are medicinal. I just said they aren't as harmful as the government propaganda has lead people to believe and there are a few that are not as harmful as some of the stuff that is available legally.
The only danger is sending out the wrong message. Drugs kill, and anyone advocating their use is little better than a killer.
Yet another person who is venomously opposed to drugs without getting the facts. I don't know about LSD but I know for a fact that after decades of study the health risks of marijuana are still debatable and there are few if any documented fatalities related to marijuana abuse.
The same goes for MDMA which is the primary ingredient of Ecstacy which has practically no ill after effects either in the short term or in the long term. Ecstacy is one place where regulation can help because the major problem with it is that most sellers cut it with harmful drugs to either enhance its effects or to short change buyers. Pure MDMA is thus hard to find so the Ecstacy consumed by most of the raver culture is actually more harmful than it has to be.
On the other hand, alcohol and cigarettes which are legal are amongst the leading causes of death in the U.S. either directly (lung and liver related diseases) or indirectly (drunk driving and second hand smoke).
The Columbia Journalism Review has a comprehensive list of the handful of corporation that control most of the news media in the United States and the rest of the world. There are a few expected faces such as AOL Time Warner, Viacom and Disney with a few surprises (General Electric, AT & T).
Where was the FCC when a handful of corporations slowly took over the media?
--
Re:No. You are being ignorant.
on
QT Mozilla Port
·
· Score: 2
It is sad that there are so many people who seem to be programmers but can't tell the difference between syntax and libraries.
From Bjarne Stroustrup's (creator of c++) book "The C++ Programming Language":
"With minor exceptions, C++ is a superset of C. Well-written C programs tend to be C++ programs as well."
Your argument only holds one way, that C++ programs cannot be compiled with libc. The only examples he gives of C code that's incompatible with C++ would lately be considered poor C.
Ouch. You just revealed that you don't understand what is being debated. The question isn't whether
C++ syntax and C syntax are similar enough to be interchangeable but whether the C library functions (e.g. strcpy, memcpy, mktime, etc) exist in libstdc++. If g++ simply uses both glibc and libstdc++ to compile programs so as to have access to both the C libraries and the C++ libraries then What is your point?
And you should really listen to his advice:
It seems you are more in need of the advice than I.
The story submitter states: Do you want to know where OO languages like Java, Ruby, Squeak, and SmallScript come from?
Although it is true that Java is heavily influenced by Smalltalk, there are also distinctive parts of Java that are based on Modula. Most prominent of which are the Exception handling mechanism and threading model based on Monitors.
The question he poses to the community is: Maybe we should throw these two toolkits at a standards body to get the best of both worlds.
I understand this and the latter half of my post addresses that.
Currently there are a sizable number of apps written in both GTK and Qt meaning that in order not to break them, any new library meant as a replacement must support both APIs almost completely which is a rather large task and is potentially unweildy since both libraries probably have lots of functions that do the same thing and thus the new library will have to contain redundant operations and also be backwards compatible with any bad design decisions made in both libraries. Backwards compatibility is always a bad start just ask Microsoft, Intel and Bjarne Stroustrup.
Of course, you chose to only respond to one side of his rebuttal. You also said: "This is like asking why you can't compile a C++ program against glibc..."
Which is exactly what I just showed.
Anyway nitpicking whether a C++ program can use C functions overlooks the original point that libraries have to have the functions you want to use. Would you have preferred if I said "That is like trying to compile a Java program against libstdc++ or a C program against rt.jar?"
You most certainly can call libc functions like 'printf' and 'fgets' from C++ programs
Really. Is this because libc is also used by g++ when compiling C++ programs or that libstdc++ reimplements the functionality of libc. Either way your argument is pointless with regards to the original point that the library needs to have the functions you require.
Write a library in C, and every single language under the sun can easily talk to it.
Oops, now I realize I'm being trolled. You got me. IHBT. IHL. HAND
--
A brief explanation of how libraries work
on
QT Mozilla Port
·
· Score: 2
I hope you are kidding about compiling a C++ program against libc or a C program against libstdc++.
You can call C functions from C++ and with a little work, you can call C++ functions from C.
You seem to misunderstand what libraries are. The question isn't whether you can use C functions from a C++ program or vice versa but whether the library functions will exist.
For instance if I compile the following C++ program against gcc which uses the C libraries
#include <iostream>
#include <string>
int void main(void){
int a=1, b =2;
string c("+");
cout <<a<<c<<b<<endl;
}
It will choke because it won't be able to find the code for a number of classes (string, ostream) and static objects (cout) because these are defined in the libstdc++ library and not glibc. It will compile fine[0] since the syntax is valid and the declarations can be found in the included header files but it will fail at link time since the needed classes and functions aren't in the libraries or source files the code is being compiled against.
[0]If gcc wasn't also a c++ compiler then it wouldn't even compile.
The story submitter states: . I hope they are able strengthen themselves financially and continue to exist. I also hope they explore new means of providing free service.
This is the major problem with the mentality that the braindead Stanford MBAs foisted on the dotcomm world and the users of the Web. A business that spends money to give away its core product away for free is doomed to failure. The notable exception to this rule is television but even then quite recently they were all money losing ventures until the rise of cheap reality-television and talk shows which garnered high ratings without being expensive to produce.
The mentality of giving things away for free fucked the dotcomm world which in turn fucked the Tech industry which in turn fucked the economy. the sooner we lose it the sooner we'll be on our road to recovery.
micheal said: The story mentions the slow slide in Great Britain when the public became convinced that surveillance would prevent crimes...
We must have read different articles. I looked at the links to Scottish crime statistics in the Wired article and although critical it admits that the incidences of certain crimes have dropped and the loss of life has been prevented on several occassions by the surveillance cameras.
I am opposed to surveillance cameras for a number of reasons chief of which is the one mentioned in the article (camera operators usually focus on minorities or young people in "hostile" outfits) as well as the loss of privacy but even I don't delude myself into thinking that they don't prevent crime.
If you want to oppose to installation of cameras, complain about the potential rights violations or 4th ammendment violations. of course with the growing rise of reality television in the U.S. if there ever was a time that this kind of action would be gotten away with, this is it. Trying to pretend that crime isn't prevented is hiding your head in the sand and won't win you any supporters if the battle against them is fought in the U.S.
The main reason that microkernels have not gained more acceptance in OS circles (although Windows NT is based on microkernel design) is that the most popular implementation of the concept (Mach) is also one of the most inefficient and badly designed.
In Joseph Liedtke's 1995 paper, On Microkernel Construction he points out that the myth of Microkernels being more inefficient and thus slower than monolithic kernels is because most benchmarks were done against the Mach microkernel.
He stated that the Mach performed poorly at both address switching and context switching and also failed to take processors into account and be optimized thusly. As a test, Liedtke wrote a Microkernel OS called L3 in which he showed that a call to getpid which took 800 cycles of kernel time on the Mach to be performed took 15 - 100 cycles on the L3.
Read his paper if you get the chance, it's very enlightening.
The ideas behind microkernel design are very sound and some of them have found their way into most mainstream OSes (Linux kernel modules can be seen as a take on the Microkernel architecture). Basically, having an OS where everything is hot swappable including memory management, process scheduling and device drivers is kind of cool. Also the fact that the usual OS level APIs can now be swapped out meaning you can have both POSIX layer and a Win32 layer on the same OS is rather nice.
But that is a risk that we should take into ourselves. If we want to create an independent, autonomous and self-sufficient industry, capable to support and protect our values, we should start to risk money.
I am all for supporting ventures that may be risky if they support Open Source ideals or are pro-consumer (I'd support any hard drive manufacturer who wa sleft if CPRM became a standard) but the Indrema situation was just a losing proposition.
Indrema planned to enter a market where companies routinely spend billions of dollars and still operate at a loss for years or sometimes never make a profit. For instance SEGA created the Dreamcast with games like Shenmue and Soul Calibur but yet they still couldn't hack it, also it has been projected that Microsoft will need at least $5 billion and 5 years before it begins to see any profits from the X-box, if all things remain equal.
All Indrema had going for them was that they planned to run linux on the OS, which doesn't mean diddly when it comes to pushing out a games console. Heck, Linux isn't even a games friendly OS yet. We are not obligated to support every brain dead business idea simply because it uses Linux or has Open Source in it's description.
Please tell me that linux isn't going to adopt the idea of having a "core" team like the BSD's do...
the only thing that will happen is that the kernel will be something that only the l33tist will be able to work on...
This has been the case for quite some time. I remember reading complaints by many would be contributors that Linux kernel development may as well be closed since it has now become so complex only a few people are able to contribute anything meaningful to it. Also Linus is notorious for not accepting patches that people have worked hard on for a variety of reasons that sometimes smack of petulence.
Anyway, exactly how do you expect the future roadmap of for the Linux kernel to be handled if not by disussions by the people who are contributing about 90% of the code? Heck just a few years ago it was done by one person, Linus, despite the number of patches that were received by the "open Source" community. It's one thing for patches and bug fixes to be handled in a bazaar manner where discussion is done via a mailing list but on the other hand when dealing with the design of the system architecture or "vision for the future" this is best done by as few people as possible. Design by committee is always bad.
Heck even Perl which has probably as many contributors as Linux gone a similar route with a fewer number of developers directing the future of the project.
Slashdot Mirror
.NET is still a vague concept to me, but one of the main guys behind it said that C# was analagous to Java the language, while .NET was analagous to Java the platform. I took that to mean the JVM and things like the EJB and Servelet standards.
.NET is the next generation of Microsoft's component technologies (COM, COM+, DCOM) which incorporates lessons learned from Java. COM is a technology that allows you to interact with components written in different languages transparently and is descended from OLE (Object Linking and Embedding which is the technology that was developed to allow being able to drag an Excel spreadsheet into a Word document) and . The languages that support COM are the Visual Studio languages as well as Object Pascal (Delphi). COM has its own binary format and while works almost transparently from Javascript, VB, and VBScript is a bitch to work with from C++. DCOM is the same as COM but it adds being able to do RPC (remote method invokation for the Java heads) from components irrespective of what language they are written in, kinda like CORBA without the ORBs.
.NET simplifies this by having a Common Language Runtime which is analogous to the Java JVM. COMable languages simply compile to the CLR format instead of to assembly code or a weird binary format. So this should lead to the best of both worlds by giving you all the functionality you have come to expect from the Java platform with the added benefit of using languages other than Java (C++, C#, VB, Javascript, VBScript, Perl and a few others) and transparently interact with objects written in these languages. Because all .NET languages have access to the CLR they can utilize it to extend themselves, e.g. Visual C++ has "managed extensions" that allows for garbage collection via the CLR.
.NET is Microsoft's XML Web services platform. This is the next generation of Internet computing, using XML to communicate among loosely coupled XML Web services that are collaborating to perform a particular task. Microsoft's .NET strategy delivers a software platform to build new .NET experiences, a programming model and tools to build and integrate XML Web services, and a set of programmable Web interfaces.
Developer View:
The major goal is then to use this technology to build XML based web services.
Marketting View:
Microsoft
--
They've come far and fast by having the right kind of smarts at the right time and place. That they didn't know they were living in a speculative bubble and far beyond their means
I refuse to believe that anybody smart (heck, anyone with an ounce of intelligence) couldn't tell that LEASING three cars for his girlfriend was a stupid idea when he was a salaried employee for a company that was extremely overvalued (they all were) and not a rich millionairre with cash in the bank.
--
6. The world is not object oriented. Even if oo is a usefull tool, it is no silver bullet.
Which makes more sense when writing an application using an object oriented programming language to develop an application? Using a database that is consistent with the programming paradigm and performs database operations transparently or one that requires the developer to go through additional hoops to get data, is generally slower, and involves writing more code?
7. RDBMS are proven technology and rather well standardised, OODBMS aren't. Currently there is a proposal for a standard (java data objects), but even that only addresses one plattform.
Not only is there a standard but the ODMG standard is on version 3, JDO is merely a Java standard. Please know the facts before flaming.
--
Hi, thanks for the responses, I didn't think anyone would be done reading it so quickly. :)
...and in an OO system some changes can be made without no effects on the existing applications. In the general case though an RDBMS is more flexible than an ODBMS.
Complexity. These systems are much more difficult to design than RDBMS. The application must be designed first, then the data structures must accomodate that. This kind of design is very expensive.
Aren't you supposed to design an application before implemnting it in any way including putting data in a DB? I've worked at two companies and had a ton of projects in school and none involved implemnting the database before the application was designed.
RDBMSs are generic. Since an OO system is designed for a specific application, it's difficult to use that system for anything else. A well-designed, properly normalized RDBMS can be used for many different applications. When a DB is going to fill many terabytes, you don't want to have multiple copies of it for each distinct reporting application.
This is simply hogwash. RDBMSs are by their nature non-generic espoecially when one adds foreign keys and constaints to a system which are necessary for any decent sized application. On the other hand the entire point of object oriented programming is creating generic reusable components. With the ability to use inheritance and polymorphism in an ODBMS I see no reason why you believe an RDBMS is more generic.
Schema changes. As mentioned in the article, schema changes are a nightmare with an OO system. In a relational system, some changes can be made with no impact on existing applications. Others are relatively uncomplicated compared to similar OO changes.
Skills availability. Yes, the old management problem. Everyone knows SQL; nobody knows OO.
Learning OODBMS techniques is mainly learning how to use another API in your bject Oriented programming language of choice (well C++, Java or Smalltalk) versus learning SQL and relational database theory. If people could learn SQL which is completely unrelated to any other aspect of their programming experience then adding OODBMS techniques as a skillset would be trivial. Of course, if people don't realize that alternatives to RDBMSs exist then they won't learn these techniques. That is more important because management can't find people who have these skills if developers don't go out and learn these techniques.
It's just not worth it. Given the dramatically higher costs associated with designing and maintaining an OO system, most applications just don't need the incremental performance gains associated with it. Very specialized, very high performance systems would benefit, but smaller or more general systems would not.
Now I just realized you didn't read the article. People have measured gains in the range of ten to a thousandfold increase in performance, these are not incremental. Secondly the primary benefit is that it means you have to write less code and don't have to worry about multiple paradigms at once when implementing an application.
Finally, where the heck are you getting this BS that designing an application with a single data model (i.e. one set of UML diagrams) is more expensive than designing one with 2 data models (i.e. an ER model for the DB, UML for the application).
--
People like the above poster and Bruce Perens make me wonder exactly where the notion of an Open Source Community and the concept of "we" comes up in this discussion. Bruce Perens does not represent the Linux kernel hackers, the Apache Foundation, the *BSD coders nor even the people that hack Slashcode. So on exactly whose behalf is he signing treaties with and who will enforce his end of the bargain?
I've previously told Bruce on kuro5hin that companies have no incentive to give up their IP and in fact will probably lose out on the deal (OpenSSH vs. SSH is a good example) and I'm yet to see a good counter argument for that. Also the fact that he has nothing to back up his threats to them with is also not encouraging. Here's an excerpt my reply to his post on K5 about that.
--
- The freedom to run the program, for any purpose (freedom 0). Check
- The freedom to study how the program works, and adapt it to your needs
(freedom 1). Access to the source code is a precondition for this. Check
- The freedom to redistribute copies so you can help your neighbor
(freedom 2). Check
- The freedom to improve the program, and release your improvements
to the public, so that the whole community benefits.
(freedom 3). Access to the source code is a precondition for this. Check
Wow, looks like the BSDL is Free Software. Please repeat after me, The GPL is not the only Free Software license. Thanks for playing. Goodbye.--
If you actually read the email, you see that they are awarding prizes and stuff for people that report requests for computers without OEM Windows installed because of a site license. Microsoft says that their site licenses do not cover new computers.
The email quoted was shown as an example and also shown to justify why they were doing it.
What MSFT is asking the OEMs to do is rat out anyone who requests a bid on PCs without asking for a quote on Windows being installed on all the machines. This is tantamount to claiming that all PCs should be running Windows or the purchasers are pirates. This then probably means that the purchaser should then expect a visit from the MSFT audit team.
It's an interesting ploy and seems reasonable when one considers that most people buying a large number of PCs would want an OS installed until one realizes that they may plan to just put Linux or *BSD on the boxes.
--
How the did the above post get modded up to +4 interesting?
Logging bugs, and giving them "severities", is well and good. It can help in the same way that any effective software development tool helps, by enhancing communication. The moral is that bug tracking is useful only in the context of a team that can, and wishes to, use it effectively.
Wrong. Software engineering practices like tracking the severity and priority of bugs are aimed at creating higher quality software. Instead of developers spending time fixing bugs that are unimportant or not as annoying to the user, they have a way of categorizing and fixing bugs on a scale of importance.
Using bug count and severity as a measure of "releasability", however, is the fallacy of feeble-minded managers, who are afraid to make a decision without a number to back it up.
Yet people like you will bitch that Microsoft shouldn't release software with known severe bugs. I guess if they didn't track bugs they would be able to say they didn't know that there were any severe bugs with a clear conscience.
Software development (as practiced in all but epsilon of cases) is simply not a measurable process. You will only waste your time trying to quantify it.
Software development can be measured based on a large number of metrics. The fact that most people refuse to use software engineering practices that have been known for decades doesn't mean that the process is "immeasurable" it simply means our industry is full of people who'd rather subscribe to the myth that programming is an art instead of trying to make it an engineering discipline.
Releasability can only be determined by the judgement of the team working on the release (which may include developers, testers, release managers, beta testers, partners, etc). That is not to say that you should not draw upon the bug database for evidence upon which to base your judgement. But it requires intelligent interpretation, not counting up some totals.
So if the members of the team come up with the rules for what makes a bug a certain severity and what marks a bug as a certain priority exactly why can they not base releasability on these metrics? Quite frankly, waiting until the software "feels right" before releasing it is probably the most ridiculuos thing I've ever heard. On the other hand saying "we won't release until all the bugs that cause core dumps/segfaults/BSODs are fixed (severity one)" or that "we won't ship until we fix the annoying UI issues (priority one or two)" are quite reasonable even from a common sense point of view.
Some people consider this a failing of the software development process. I think they are too quick to condemn. The customer doesn't (usually) judge software by its bug count.
Interestingly most users of Windows 98 I know judged the software on its bug count (i.e. how many crashes needing reboots per day or other ridiculuos problems per day)
Most software is judged by an overall feel: if the software is compelling, many deficiencies will be overlooked. Further, it is difficult to guess ahead of time (even with beta testing) which bugs will really bite people and impede their use of the software.
If beta testers don't give you a feel for a large number of the bugs that will bite people on the ass then there are flaws in your beta-testing process.
Given the many interacting factors that determine the success of software, release decisions are naturally more art than science.
People like you are the major problem with the software industry. Those that believe that even though there have been increasing strides in the field of sooftware engineering, we should all still practice software development like it is a black art handed down from master to apprentice in a scene reminescent of guilds of the middle ages.
I know, I haven't presented any hard evidence. I'm arguing from experience in both free and closed software projects, and appealing to common sense. Most free software is released "when it's ready", without any metrics. Ponder on whether this is a strength or a weakness. And remember that when someone gives you number, the burden is on him to show that the number means something.
Do you really think Mozilla, GNOME, KDE, Apache, the Linux kernel, OpenBSD, etc are shipping "stable" releases of software without keeping an eye on bug severities and priorities? They may choose to ignore them for one reason or the other but they are keeping track.
--
It seems you are refering to this post of mine a while ago. For proof of Mach's deficiencies I linked to two research papers; On Microkernel Construction and The Impact of Operating System Structure on Memory System Performance in that post. If you want the capsule summary then here's a short list of Mach's deficiencies as posed by Liedtke
- Inefficient kernel-user switching (i.e. system calls spend too much unecessary time in the kernel).
- Inefficient address switching (i.e. the number of cache and TLB misses in the Mach microkernel is also absurdly large).
- The performance of IPC operations and thread switching is subpar. (this is related to the above points).
- It isn't optimized for specific hardware and instead has a Hardware Abstraction Layer which slows it down considerably.
The paper is a few years old so the Mach people may have tackled some of these problems by now.If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel? Are any well-designed microkernels out there?
Neutrino and EROS to name two.
If there are, then what is it that repeatedly leads projects like xMach/HURD/OS X/mkLinux to embrace Mach as opposed to one of the competing microkernels?
The same reason most of us are using Java and C++ instead of SmallTalk, Lisp or Objective-C. Developer inertia and people falling to the more hyped and/or better sold technology.
and, btw, this is kind offtopic, but while we're VAGUELY near the subject: someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true? How does that work in terms of sharing the hardware? How do you go about doing this?
A microkernel can load different modules at runtime that may be OS emulation layers that mimic the behaviors of certain OSes even down to memory management and paging. Since you can theroetically load as many modules as you want, you can load various emulation layers and mimic several OSes at once. For instance OS X has a microkernel that loads modules to mimic BSD as well as old Apple APIs (Classic) as well as teh new stuff (Carbon). Here's a graphical look at how the MacOS X architecture.
--
Bjarne Stroustrup recently had an interview with LinuxWorld where he outlined his plans for the future of C++. Here's an in article that analyzes and contemplates the ramifications of these changes.
Don't expect these changes anytime soon though. From recent ACCU meetings it seems that most of the C++ standard from 1997 still hasn't been implemented now let alone new libraries that are yet to be designed. The soonest I see any of Bjarne's ideas being usable by developers and standardized is 2005 if the rate of compiler and library development continues at the current rate.
--
Isn't this just doing stuff similar to what strong validators a là Entity Tags in HTTP requests and responses use for determining whether a page has been changed (i.e. is in the cache) or not?
The only difference I can see is that they generate an Etag like entity for tect highlighted by the user as well as the entire webpage. Doesn't seem worthy of a patent though.
--
Interesting arguments. You realize that the Prohibition is exactly like the War on Drugs with regards to the minor drugs like Ecstacy and Marijuana. Here are some articles about the war on drugs.
I'll just mention the major similarities
- Increased consumption of substance (currently a third of Americans have used Marijuana)
- Expenditure on substance increases because a.) demand for it is inelastic and b.) it becomes more scarce.
- Violent gang wars over illicit profits.
- People criminalized for activity that harmed no one but themselves.
Point me to some studies showing the medical benefits of drugs if you can. And not ones conducted by fronts for organisations like NORML which advocate making drugs available to everyoneI didn't argue that drugs are medicinal. I just said they aren't as harmful as the government propaganda has lead people to believe and there are a few that are not as harmful as some of the stuff that is available legally.
--
The only danger is sending out the wrong message. Drugs kill, and anyone advocating their use is little better than a killer.
Yet another person who is venomously opposed to drugs without getting the facts. I don't know about LSD but I know for a fact that after decades of study the health risks of marijuana are still debatable and there are few if any documented fatalities related to marijuana abuse.
The same goes for MDMA which is the primary ingredient of Ecstacy which has practically no ill after effects either in the short term or in the long term. Ecstacy is one place where regulation can help because the major problem with it is that most sellers cut it with harmful drugs to either enhance its effects or to short change buyers. Pure MDMA is thus hard to find so the Ecstacy consumed by most of the raver culture is actually more harmful than it has to be.
On the other hand, alcohol and cigarettes which are legal are amongst the leading causes of death in the U.S. either directly (lung and liver related diseases) or indirectly (drunk driving and second hand smoke).
Anyway, the War On Drugs is an acknowledged failure. As large a percentage of the U.S. population uses drugs as those in countries where the usage of certain drugs is not as frowned upon. The only successful thing about the war on drugs is that it has enabled the government to pass laws abridging due process (various seizure laws) and circumvent the 4th Ammendment.
This response is paraphrased from an earlier response on kuro5hin.
PS: If you want to read insightful discussion on the War On Drugs, I suggest reading one of the following articles and a few of the comments posted, Why Drugs Should Be Illegal or More Cluelessness In The War On Drugs.
--
The Columbia Journalism Review has a comprehensive list of the handful of corporation that control most of the news media in the United States and the rest of the world. There are a few expected faces such as AOL Time Warner, Viacom and Disney with a few surprises (General Electric, AT & T).
Where was the FCC when a handful of corporations slowly took over the media?
--
It is sad that there are so many people who seem to be programmers but can't tell the difference between syntax and libraries.
From Bjarne Stroustrup's (creator of c++) book "The C++ Programming Language": "With minor exceptions, C++ is a superset of C. Well-written C programs tend to be C++ programs as well."
Your argument only holds one way, that C++ programs cannot be compiled with libc. The only examples he gives of C code that's incompatible with C++ would lately be considered poor C.
Ouch. You just revealed that you don't understand what is being debated. The question isn't whether C++ syntax and C syntax are similar enough to be interchangeable but whether the C library functions (e.g. strcpy, memcpy, mktime, etc) exist in libstdc++. If g++ simply uses both glibc and libstdc++ to compile programs so as to have access to both the C libraries and the C++ libraries then What is your point?
And you should really listen to his advice:
It seems you are more in need of the advice than I.
--
The story submitter states:
Do you want to know where OO languages like Java, Ruby, Squeak, and SmallScript come from?
Although it is true that Java is heavily influenced by Smalltalk, there are also distinctive parts of Java that are based on Modula. Most prominent of which are the Exception handling mechanism and threading model based on Monitors.
--
The question he poses to the community is: Maybe we should throw these two toolkits at a standards body to get the best of both worlds.
I understand this and the latter half of my post addresses that.
Currently there are a sizable number of apps written in both GTK and Qt meaning that in order not to break them, any new library meant as a replacement must support both APIs almost completely which is a rather large task and is potentially unweildy since both libraries probably have lots of functions that do the same thing and thus the new library will have to contain redundant operations and also be backwards compatible with any bad design decisions made in both libraries. Backwards compatibility is always a bad start just ask Microsoft, Intel and Bjarne Stroustrup.
--
Of course, you chose to only respond to one side of his rebuttal. You also said: "This is like asking why you can't compile a C++ program against glibc..."
Which is exactly what I just showed.
Anyway nitpicking whether a C++ program can use C functions overlooks the original point that libraries have to have the functions you want to use. Would you have preferred if I said "That is like trying to compile a Java program against libstdc++ or a C program against rt.jar?"
You most certainly can call libc functions like 'printf' and 'fgets' from C++ programs
Really. Is this because libc is also used by g++ when compiling C++ programs or that libstdc++ reimplements the functionality of libc. Either way your argument is pointless with regards to the original point that the library needs to have the functions you require.
Write a library in C, and every single language under the sun can easily talk to it.
Oops, now I realize I'm being trolled. You got me. IHBT. IHL. HAND
--
You can call C functions from C++ and with a little work, you can call C++ functions from C.
You seem to misunderstand what libraries are. The question isn't whether you can use C functions from a C++ program or vice versa but whether the library functions will exist.
For instance if I compile the following C++ program against gcc which uses the C libraries It will choke because it won't be able to find the code for a number of classes (string, ostream) and static objects (cout) because these are defined in the libstdc++ library and not glibc. It will compile fine[0] since the syntax is valid and the declarations can be found in the included header files but it will fail at link time since the needed classes and functions aren't in the libraries or source files the code is being compiled against.
[0]If gcc wasn't also a c++ compiler then it wouldn't even compile.
--
More to the point, why doesn't QT allow me to compile GTK apps against it, or vice versa?
Because they are different libraries. This is like asking why you can't compile a C++ program against glibc or compile a C program with libstdc++.
It looks like you are asking for someone to write a library that exports both the GTK APIs and the Qt APIs which would be a phenomenal amount of work.
--
The story submitter states:
. I hope they are able strengthen themselves financially and continue to exist. I also hope they explore new means of providing free service.
This is the major problem with the mentality that the braindead Stanford MBAs foisted on the dotcomm world and the users of the Web. A business that spends money to give away its core product away for free is doomed to failure. The notable exception to this rule is television but even then quite recently they were all money losing ventures until the rise of cheap reality-television and talk shows which garnered high ratings without being expensive to produce.
The mentality of giving things away for free fucked the dotcomm world which in turn fucked the Tech industry which in turn fucked the economy. the sooner we lose it the sooner we'll be on our road to recovery.
--
micheal said:
The story mentions the slow slide in Great Britain when the public became convinced that surveillance would prevent crimes...
We must have read different articles. I looked at the links to Scottish crime statistics in the Wired article and although critical it admits that the incidences of certain crimes have dropped and the loss of life has been prevented on several occassions by the surveillance cameras.
I am opposed to surveillance cameras for a number of reasons chief of which is the one mentioned in the article (camera operators usually focus on minorities or young people in "hostile" outfits) as well as the loss of privacy but even I don't delude myself into thinking that they don't prevent crime.
If you want to oppose to installation of cameras, complain about the potential rights violations or 4th ammendment violations. of course with the growing rise of reality television in the U.S. if there ever was a time that this kind of action would be gotten away with, this is it. Trying to pretend that crime isn't prevented is hiding your head in the sand and won't win you any supporters if the battle against them is fought in the U.S.
The main reason that microkernels have not gained more acceptance in OS circles (although Windows NT is based on microkernel design) is that the most popular implementation of the concept (Mach) is also one of the most inefficient and badly designed.
In Joseph Liedtke's 1995 paper, On Microkernel Construction he points out that the myth of Microkernels being more inefficient and thus slower than monolithic kernels is because most benchmarks were done against the Mach microkernel. He stated that the Mach performed poorly at both address switching and context switching and also failed to take processors into account and be optimized thusly. As a test, Liedtke wrote a Microkernel OS called L3 in which he showed that a call to getpid which took 800 cycles of kernel time on the Mach to be performed took 15 - 100 cycles on the L3.
Also he also disproved the notion that using a microkernel leads to memory degradation due to a large number of cache misses a dissects a number of benchmarks from Chen and Bershad's paper The Impact of Operating System Structure on Memory System Performance.
Read his paper if you get the chance, it's very enlightening.
The ideas behind microkernel design are very sound and some of them have found their way into most mainstream OSes (Linux kernel modules can be seen as a take on the Microkernel architecture). Basically, having an OS where everything is hot swappable including memory management, process scheduling and device drivers is kind of cool. Also the fact that the usual OS level APIs can now be swapped out meaning you can have both POSIX layer and a Win32 layer on the same OS is rather nice.
But that is a risk that we should take into ourselves. If we want to create an independent, autonomous and self-sufficient industry, capable to support and protect our values, we should start to risk money.
I am all for supporting ventures that may be risky if they support Open Source ideals or are pro-consumer (I'd support any hard drive manufacturer who wa sleft if CPRM became a standard) but the Indrema situation was just a losing proposition.
Indrema planned to enter a market where companies routinely spend billions of dollars and still operate at a loss for years or sometimes never make a profit. For instance SEGA created the Dreamcast with games like Shenmue and Soul Calibur but yet they still couldn't hack it, also it has been projected that Microsoft will need at least $5 billion and 5 years before it begins to see any profits from the X-box, if all things remain equal.
All Indrema had going for them was that they planned to run linux on the OS, which doesn't mean diddly when it comes to pushing out a games console. Heck, Linux isn't even a games friendly OS yet. We are not obligated to support every brain dead business idea simply because it uses Linux or has Open Source in it's description.
Please tell me that linux isn't going to adopt the idea of having a "core" team like the BSD's do ...
the only thing that will happen is that the kernel will be something that only the l33tist will be able to work on ...
This has been the case for quite some time. I remember reading complaints by many would be contributors that Linux kernel development may as well be closed since it has now become so complex only a few people are able to contribute anything meaningful to it. Also Linus is notorious for not accepting patches that people have worked hard on for a variety of reasons that sometimes smack of petulence.
Anyway, exactly how do you expect the future roadmap of for the Linux kernel to be handled if not by disussions by the people who are contributing about 90% of the code? Heck just a few years ago it was done by one person, Linus, despite the number of patches that were received by the "open Source" community. It's one thing for patches and bug fixes to be handled in a bazaar manner where discussion is done via a mailing list but on the other hand when dealing with the design of the system architecture or "vision for the future" this is best done by as few people as possible. Design by committee is always bad.
Heck even Perl which has probably as many contributors as Linux gone a similar route with a fewer number of developers directing the future of the project.