Building programs is to Computer Science as Building microwave ovens is to Physics.
Re:Making money from it
on
Hack This, Please
·
· Score: 2, Insightful
Concerning liability, companies are rightly paralyzed with fear that they could be held responsible for making a product that can be modified to do illegal and/or unpleasant things.
Pah. Without modification, I can use knives intended to carve food to kill others instead.
Put all your eggs in one basket! Yessiree, this basket will hold any kind of egg, and very many eggs too!
The Windows registry is not easy to repair, having a binary on-disk format. What is worse, is that the most important things (system and personal settings) are condensed into one single database file each.
Config files have the benefit of being able to hook into the filesystem permissions, by sheer virtue of being a file.
Additionally, by seperating out each configuration file, there is no single point of failure. (Other than rm -rf/etc ; or equivalent corruption)
Anyway. If you want a key-value registry, look at gconfd of GNOME. (Even that isn't a single monolithic database, it is actually stored as a folder hierarchy on disk, and the file format is based on XML)
Something that I learned in statistics is that, when you deal with dataset with a very large variance, it is best to present the average as the median rather that the mean.
That, and the median has the nice by-definition property of having (in theory) 50% of the sample/population below it.
But I'm sure both Mono and the Java class library have non-native portions. Especially where interfacing with GUIs is concerned. And that's not the only thing. Other low-level-ish things need to be ported, like networking, remote invocation etc.
Obviously, porting the small app is easier. However, in the big picture:
* Porting millions of small/medium/large apps
or
* Porting one huge library and app
and you see the benefits. However... in the case of JRE+JVM and.net+CLR, neither have been ported to very many platforms.
Of course, this argument completely ignores the differences in featureset between non-Oakian (a new term I am coining for Java-like programming languages (not Java-like runtime libraries)) and Oakian programming languages.
All you have to do is to add an object to some statically-scoped container (list, array, dictionary etc.) and forget to remove it when you're done.
Debugging leaks in garbage collected systems can be very difficult. Similiar leaks can happen in non-GCed systems though, and they're equally hard to find.
A rant about the state of the current OS X Finder, and its non-intuitivity for spatially-oriented persons (i.e. most everybody who lives in meatspace). The spatial finder. But, once you get used to it, I think that the current single-window-change-current-window model is acceptable. But it can be highly confusing to people who are spatially oriented. Such people prefer files/icons in the computer to act like objects in the real world: stay where they last put them (assuming no one else moves them).
You can almost draw a simple text editor into existence on Mac OS X. The only code needed is the serialisation/deserialisation stuff. And even that is trivial.
But otherwise, the parent is right. Coding an non-trivial program is non-trivial; coding a GUI on top of that even more so.
The grandparent will have to wait until software component-oriented programming becomes popular. After all, why reinvent the (exact same) wheel over and over again if you can provide a stock software component that does the trick? It is like the electronic component revolution really -- you don't really have to worry about fabricating resistors or transistors or LEDs anymore -- just worry about how to put them together (so that it works). From there, it is just solder and dike.
Slashdot Mirror
An open window in the wall is an open port in the firewall.
A shotgun is for pre-emptive blocking measures.
Distributed Denial of Service is best carried out by sending out DDoS packets on hawks.
RFC 2549: IP over Avian Carriers with Quality of Service
PowerPC is quite open. The Mac architecture is mostly open. The difference is, for the most part, there are few suppliers of PowerPC/Mac hardware.
Then again... I think the show-stopper for custom Mac builders will be Apple's patents. (and proprietary I/O controllers)
OpenCores
Open CPUs for all!
We'll begin the lawsuits with 127.0.0.1!
Hmm hmm? I thought the most common source of fullerines was common ash and soot?
Proton is the name of a Malaysian automobile company.
Proton is also the name of the positively charged particle in the nucleus of atoms.
They can't sue Microsoft for software-failure-related reasons -- they signed that right away in the EULA.
Who knows. Maybe they'll pull a Squaresoft and call it Mac OS X-2.
Not quite. I believe that:
Building programs is to Computer Science as
Building microwave ovens is to Physics.
Pah. Without modification, I can use knives intended to carve food to kill others instead.
To be exact, it is an Akamai site. Which provides caching and other measures that prevent sites from suffering /. attacks.
It is also the reason why Microsoft.com appeared to run Linux.
Hm. Now that I look at that, my last commment doesn't make sense.
"In the PC world, anything other than an Opteron machine can't compare"
Hm. Apple PowerMac G5:
* HyperTransport
* PCI-X / AGP
* DDR SDRAM
* S-ATA
* Gigabit Ethernet
* IEEE 1394b a.k.a. Firewire 800
* USB 2.0
So, tell me, which of these, which will be the only interfaces that you can sanely use, is proprietary?
In the PC world, anything other than an Opteron machine can compare in specs.
APPL!?
What does Appell Petroleum Corporation (APPL.PK) have to do with Apple Computer?
You must mean AAPL.
Put all your eggs in one basket! Yessiree, this basket will hold any kind of egg, and very many eggs too!
/etc ; or equivalent corruption)
The Windows registry is not easy to repair, having a binary on-disk format. What is worse, is that the most important things (system and personal settings) are condensed into one single database file each.
Config files have the benefit of being able to hook into the filesystem permissions, by sheer virtue of being a file.
Additionally, by seperating out each configuration file, there is no single point of failure. (Other than rm -rf
Anyway. If you want a key-value registry, look at gconfd of GNOME. (Even that isn't a single monolithic database, it is actually stored as a folder hierarchy on disk, and the file format is based on XML)
The Patent Office could do with more people who could actually judge inventions properly.
The Patent Office could do with more Einsteins.
Something that I learned in statistics is that, when you deal with dataset with a very large variance, it is best to present the average as the median rather that the mean.
That, and the median has the nice by-definition property of having (in theory) 50% of the sample/population below it.
The Java class library is written mostly in Java.
But I'm sure both Mono and the Java class library have non-native portions. Especially where interfacing with GUIs is concerned. And that's not the only thing. Other low-level-ish things need to be ported, like networking, remote invocation etc.
No need for either.
XUL already exists. XAML is a XUL feel-alike, like C# is to Java.
Pah. It always takes Microsoft to bring already-existing ideas into the spotlight.
Also, the article seems to talk up hype about XAML, when XUL already does the same thing, and, more importantly, XUL is not vapourware.
Hmm. Similiarly, I don't think there was much interest in doing GNOME in Java until Microsoft released their Java feel-alike.
Which is easier:
.net+CLR, neither have been ported to very many platforms.
* Porting one small app
Or
* Porting one huge library and app
Obviously, porting the small app is easier. However, in the big picture:
* Porting millions of small/medium/large apps
or
* Porting one huge library and app
and you see the benefits. However... in the case of JRE+JVM and
Of course, this argument completely ignores the differences in featureset between non-Oakian (a new term I am coining for Java-like programming languages (not Java-like runtime libraries)) and Oakian programming languages.
Even with garbage collection, leaks are possible.
All you have to do is to add an object to some statically-scoped container (list, array, dictionary etc.) and forget to remove it when you're done.
Debugging leaks in garbage collected systems can be very difficult. Similiar leaks can happen in non-GCed systems though, and they're equally hard to find.
A rant about the state of the current OS X Finder, and its non-intuitivity for spatially-oriented persons (i.e. most everybody who lives in meatspace).
The spatial finder.
But, once you get used to it, I think that the current single-window-change-current-window model is acceptable. But it can be highly confusing to people who are spatially oriented. Such people prefer files/icons in the computer to act like objects in the real world: stay where they last put them (assuming no one else moves them).
How to do it.
But otherwise, the parent is right. Coding an non-trivial program is non-trivial; coding a GUI on top of that even more so.
The grandparent will have to wait until software component-oriented programming becomes popular. After all, why reinvent the (exact same) wheel over and over again if you can provide a stock software component that does the trick? It is like the electronic component revolution really -- you don't really have to worry about fabricating resistors or transistors or LEDs anymore -- just worry about how to put them together (so that it works). From there, it is just solder and dike.