You're reading the chart wrong. The chart states that the iPhone 3G, released in June 2008, ran the current OS for three years after release, which is correct: the iPhone 3G was updated to iOS 4.2.1, which was released on November 22, 2010, and it continued to run the current major iOS 4.x series until iOS 5 was released in October 2011. (Granted, it stopped receiving updates in March 2011 with iOS 4.3, but that was still the same major version series.)
The iPhone 3GS, meanwhile, will likely get support for at least 4 years, given that Apple is still selling the iPhone 3GS and, historically, provides at least 2 years of support.
As for the Samsung Galaxy, which Galaxy? The Samsung i5500 is pre-loaded with Android v2.1, in the summer of 2011. That's 2 major releases behind!
The primary difference is, instead of needing to create user interfaces purely atop GL, you can use the CocoaTouch libraries and get native buttons, frames, html controls, etc.
Microsoft did rebuild Windows from the ground up as a modern operating system. That was Windows NT (as compared with Windows 3.0) back in 1993. Thus, they predated the "let's rebuild the OS from scratch" thing that Apple did by 8 years.
That said, even as a modern operating system, it has a number of anachronisms kept primarily for backward compatibility with legacy 16-bit code, and has even more backward compatibility "hacks" for poorly written 32-bit apps (see the oldnewthing archives -- lots of apps do stupid things), but their priority is keeping existing code working, instead of breaking existing (poorly written) apps. I can't fault them for this.
The only thing removing such anachronisms would do is prevent older programs from working, which really does no one any good (unless you like the thought of Microsoft shooting their own lower-torso off...)
Don't get me started on the x86 (little endian, lack of registers, CISC instruction set, etc.)
Why not?
What's wrong with little endian? Aside from the fact that network-byte-order is big endian, I see nothing wrong with it. In fact, little endian has an advantage, at least in theory: arbitrary sized arithmetic. You could always add two numbers together, a byte at a time, check the carry flag, and then progress to the next byte, for *any* size number. This would allow trivial addition of multi-gigabyte numbers in very little assembly.
Lack of registers is largely rectified in AMD64/ie32e, in which 16 GP registers exist. Sure, it's not the 32 registers of PPC (or the 128 of Itanium), but it's sufficient for most code. It really doesn't matter anyway, since the CPUs keep track of dozens of registers internally as part of the internal register renaming system...
CISC? You must be kidding. Sure, the instruction set is CISC, but the internals of x86 CPUs have been RISC-like since the Pentium, with a hardware instruction decoder that converts legacy x86 instructions into internal RISC-like instructions. It's largely a non-issue today. (Yes, the hardware decoder takes up more die space, but it's a fixed size, and a constantly shrinking amount of die space as the dies keep getting bigger with Moore's law.) Plus, CISC acts as a sort of compression scheme, so that CISC programs are smaller than the equivalent RISC programs, resulting in lower memory pressure when loading/executing the code -- all good things when memory keeps getting slower and slower relative to the CPU.
There's really nothing fundamentally wrong with x86. If there were, it wouldn't be used as widely as it is (because if it were fundamental it couldn't be easily fixed).
(a) does the VB.NET environment support most of Windows Forms
Mono has had complete System.Windows.Forms 1.1 API support since Mono 1.2. System.Windows.Forms 2.0 is still being worked on, with the missing methods reported by MoMA getting implemented first.
(b) does it support database access through ODBC, OLE DB, some equivalent to the.NET native providers, or some combination of the above
Mono has many System.Data providers, including System.Data.Odbc, System.Data.OleDb, System.Data.OracleClient, and System.Data.SqlClient, though I can't say how complete these are. You will likely need to test your code.
(c) can it expose and consume Web services with reasonable ease
Mono has had ASP.NET support for quite some time, as well as.NET Remoting, so ASP.NET web services (.asmx files) and.NET Remoting web services are both supported.
Apple has to charge different prices in different countries becuase Apple needs to license the music separately for each country, and the licensors in each country may want to charge different prices (and restrict what can be licensed!).
Consider books: you write a book, and it gets published. If some other publisher wants to sell your book in a different country, that publisher will need to talk to you (assuming you remain the copyright owner). However, it's quite likely that a different country will speak a different language, so your book will need to be translated, adding additional expense which the publisher will want to recoup. Result: the book in the other country costs more to purchase than just purchasing your original book + shipping it.
"But this adds translation charges, which aren't at issue here!" True, but translations aren't the only source of additional fees. The countries copyright association may require blanket fees in order to handle copyright infringement (consider blank media -- CD-Rs, tapes, etc. -- which includes such hidden fees), and this will need to be handled by all licenses.
Summary: Apple (probably) can't set a worldwide price because it (probably) can't get licenses which would permit a single worldwide price.
Wine is most certainly a reverse engineering effort. The problem is that you don't fully understand what reverse engineering includes.
Reverse engineering also includes the following process:
Write test (e.g. figure out some undocumented detail for CreateProcess)
Run test, get results (CreateProcess doesn't format your hard drive)
Write your own code to duplicate the results of the test written in (1)
Repeat 1..3 until complete.
This is black box reverse engineering. You treat some piece of software as a block box, write tests for it, figure out what the "box" is doing, and recreate that behavior. No decompilation required, no source code required, just lots of tests and ingenuity. This has the benefit that no copyright violations are required (since you never decompile the original program). This process is also used in clean room design, except step 3 is replaced with a documentation step -- instead of code being the result of the process a specification is the result. Compaq did this to reverse-engineer the IBM PC BIOS.
Wine is most certainly doing this, as it's the only way to determine undocumented connections between various APIs. Mono certainly does this ("what's this member supposed to do, and is Mono's version following that behavior properly?"). Another way to think of this is for bugs -- does this Mono code do what the.NET equivalent code does? If not, we'll get a bugzilla entry for it, and (eventually) fix it. This bug-report/fix cycle can also be considered as black box reverse engineering, since the bug-report is itself a test, through which we can determine what the actual functionality should be.
Decompilation is generally not legal, since it can lead to copyright violations. Black box reverse engineering is legal, and any attempt to limit black box reverse engineering would kill the interoperability market, since no compatible hardware/software could ever be created unless the original manufacturer permitted it.
Don't contributors assign copyright to some type of Linux foundation?
No. Linux kernel contributors retain their own copyright. This is frequently considered to be a good thing, as it means that no single group has copyright over everything, which means that no single group can change the license to e.g. BSD and start selling a proprietary version of Linux.
what then happens 17-20 years later, when all the patents expire?... [T]here are lots of parties who depend on expired patents for their businesses (generic drugs, eg) so there would be a strong lobby against that for a change.
You'd like to think that, but you'd be wrong. Yes, there are people who would lobby for the patents expiring, but their lobbying would be useless. In the drug world, patents do indeed expire. And the still can't be manufactured generically because the drug companies file a new patent combining the generic drug with another (potentially generic) drug, selling them as a combined unit. For bizarro reasons, this prevents the original drug from being freely reusable.
So for story line patents, when a patent expires, a new patent will be filed combining the expired patent with a new idea, creating a new patent, thus perpetuating the problem. Fun for all involved!
so what you are saying is if someone working in California should be paid more money than someone working in West Virginia doing the same job, because its cheaper to live in WV??
Actually, this is exactly the case. Houses in California cost $500,000 (or more!) for something that would cost $200,000 (or less!) in Rochester, NY (never mind West Virginia). That's also why we have Cost of Living calculators, to better compare our current salary to what we'd need to live equivalently elsewhere (due to food, gas, rent, mortgage, dining...); for example if you earn $50,000 in Bluefield, WV, you would need to make $134,050 in Menlo Park, CA to have an equivalant lifestyle.
This isn't a "new era" of "geo-discrimination," this has always been the case (though it has gotten worse as the housing bubble gets larger).
There may not be a Microsoft.NET Framework for Unix or Linux, but there is a (largely).NET-compatible implementation in Mono.
Mono isn't 100% compatible with all of.NET, and may never be (infrequently used parts haven't been implemented, such as System.EnterpriseServices, System.Messaging, COM Interop, etc.), but what it does provide is an implementation of the underlying ECMA standards (for C# and for the Common Language Infrastructure), plus an effort for.NET compatibility in all that is reasonable (I/O, XML, app configuration, ASP.NET support via XSP and mod_mono, Database access, and more). Initial support for System.Windows.Forms is planned for the next release, 1.2, due around September.
Now, I'm not saying that any piece of.NET software will be able to run unchanged under Mono. In general, this isn't possible as it could rely on Windows-specific functionality, such as COM Interop, or rely on Windows-specific libraries. I am saying that Mono provides a portable base to build software upon, much as the ANSI C and the POSIX.1 standards do. You can write portable software, but you are not required to do so. Guidelines for writing portable.NET code can be found in the book Cross-Platform.NET.
Why another back-end, yes GCC does not support JIT but you could have used LLVM for that.
The JIT isn't the issue. The intermediate language is, or rather was, the issue. When Mono was started, GCC used a register-based intermediate language. It is difficult to translate a register-based intermediate language to a stack-based intermediate language.
Look at the GCC/Java backend, which skips the entire register-based intermediate layer; the GCC/Java project basically re-wrote the GCC back-end to avoid the register layer. Because of this, you couldn't compile any GCC-supported language to Java bytecode, such as C, C++, FORTRAN, Ada, because they all targeted the register IL instead of Java's stack-based IL.
Things are somewhat different as of GCC 4, due to the GIMPLE architecture which should support stack-based architectures such as Java bytecode and CIL. However, GCC 4 didn't exist when Mono was started (it doesn't exist now, except in beta form), so it obviously couldn't be used as part of Mono.
Another thing is Mono developers don't seem to listen to some of the GCC developers when it comes to algorithms, one example is their PRE implementation is based on much slower and not as good algorithm as the one which GCC uses GVN/PRE.
I can't speak to the truth of this, but I can say that I haven't seen any comments from GCC developers on the mono mailing lists regarding the SSAPRE algorithms. I can't think of any messages from a GCC developer on the mono lists, actually...
From gcj prospective:
(again) Why another back-end?
Why another ABI, instead of hooking gcj and Mono together, there is another static ABI?
Another backend was necessary because CIL and Java bytecode are different. Differences are outside the scope of this, but one difference is whether or not types are part of the opcodes -- compare Java's iadd, ladd, fadd, dadd to CIL's add opcode. Generics add a further difference -- compare Java's type erasure to the "baked-in" generics support of CIL.
To support CIL at all, you need to support another backend, just to support the differences between Java bytecode and CIL. Alternatively, you can argue that CIL shouldn't be supported, which would tie.NET developers to Windows without any chance of migrating to another platform.
There is little doubt that Free- and open-source software infringes someone's patents. To some extent this has been covered before; see older slashdot stories. Then you have the random patents such as the JPEG patents (thought JPEG was patent-free? ha!). MPEG is also covered by several patents. Just because there hasn't been a lawsuit doesn't mean that patents aren't present.
There is little doubt that closed-source software infringes someone's patents; see all the lawsuits against Microsoft, Sun, and anyone else of consequence.
You want to see the violations? Really? Are you sure?
I ask because if you know about a patent and then try to work around it, if you're found infringing you're subject to treble damages. It's far better to live in ignorance and not know what patents you're potentially infringing; that way you're only subject to 1x damages, not 3x, and that's only if you lose the patent case. Linux Torvalds has said as much several times.
This is why the software patent situation is so crazy: everything is covered. Anything and everything, no matter how trivial, has either been patented or will be patented; it's only a matter of time.
Which is why it doesn't matter if PHB's think that Linux is risky, as long as they realize that everything is risky. Patents are just a shell game to keep independant developers down; only big business -- or patent shell companies -- gain in this climate.
It's time that we had a new ASCII. That standard should be binary XML.
One minor question: How do we debug this?:-)
The nice thing about plain text (ASCII) is that I can open it in an editor and read it, without worrying that my editor may be screwing things up. I can't do that with Binary XML.
If we did as you propose, I couldn't easily examine the output of my program. I'd instead have to load the output of my program in Super Notepad to view the output. And if my Binary XML functions are buggy? Super Notepad is no longer a help. So what do I do? Start adding print statements to get plain text output back, allowing me to understand what's actually happening. (Sure, I could use a debugger too, but I need some context to find where the bug is, so I'll need ASCII output at some point...)
The last thing I need is yet another layer of binary madness between me and the data I'm trying to interpret. That way lies madness.
Could a processor be made twice as fast if it could be made twice the size?
In contrast to all the other responses (discussing signal propogation time and other issues), here's a different observation:
This has already happened (somewhat), and is continuing to happen.
How so? Adding additional integer and floating point units increases the processor size and performance. As does better branch prediction code. As does Level 1 Cache.
Then there are the modern marvels such as SMT (aka HyperThreading), or even putting multiple cores onto the same die (see IBM's POWER series, and AMD and Intel will be doing this too).
The key point of Herb Sutters article is that CPUs will continue to advance (more CPU cores, better HyperThreading, more Cache), will continue to get bigger, but all these advances won't be increasing MHz. Consequently, none of these advances will help single-threaded code. Concurrency is the only way to increase performance now.
My apologies for the horrible look of the code samples. Slashdot won't let me use nice, short lines, as it results in lines which are too short. Gah! Apparently I need ~40 characters per line (average) to get past the @#$% filter... This has to be the most annoying filter I've ever come across; I've spent more time getting past the filter than responding to your question!
Iterators are similar to java.util.Iterator. C# iterators are compiler support for implementing the System.Collections.IEnumerator interface. For example, in Java you'd write:
public class MyIterator implements Iterator { private String[] hw = {"hello", "world"}; private int pos = 0; public boolean hasNext () { if (pos >= 0 && pos < hw.length) return true; return false; } public Object next () {return hw[pos++];} public void remove () {throw new UnsupportedOperationException ();} }
public void UseIterator () { Iterator e = new MyIterator (); while (e.hasNext()) System.out.println (e.next().toString());}
public void UseIterator () { foreach (string s in SayHello()) Console.WriteLine (s);}
C# iterators are particularly useful when implementing your own collection objects. Google for them; they're very powerful.
Anonymous Methods are methods without a name, just like Java anonymous classes are classes without a name. Same basic idea, fewer braces. They also act as full closures; while Java requires that all stack variables referenced from an anonymous class be final, C# doesn't require this.
int n = 42; EventHandler h = delegate {Console.WriteLine ("something happened:" + n);}; h ();
The above example is bad, but you can let your imagination run wild. This is very useful for event handlers.
Partial Types
allow you to split a single class definition across multiple files. This is useful to prevent > 50 KB source files (yech!), and makes it easier to have part of a class machine generated (by a GUI builder) and part hand-written. Some people hate it, others are ambivalent, but it can be handy:
// File a1.cs partial class Foo {public int a;}
// File a2.cs partial class Foo {public int b;}
Nullable types are primarily useful for database support in the.NET type system. DB types can be "nullable" -- not present. For reference types, this is easy -- use null. For.NET value types, this isn't possible, as value types can't be null. The solution is to introduce a generic class System.Nullable<T>, which can wrap value types such as int.
The C# compiler adds syntactic sugar to this, to simplify usage:
int? nullable_int = GetMyNullableInt (); if (nullable_int.HasValue)/* use nullable_int */
Nullable types are more special purpose, but are useful for those who need them.
Ignore the rest of this: it's just garbage to get past Slashdot's wonderful "too few characters per line" problem: lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja the quick brown fox jumps over the lazy dog l;kajdsfl;kj;lkj l;kjasdilfj l;kjoiewqruq[op 0-9314u75 lkfjx;lkajdsfmopiac un0p3u5n1-0329u kl 0a9u 3214o5ilj hello out there in tv land! q 09
ECMA-335, which the grand-parent referenced, standardizes some of the class libraries. In particular, this file contains All.xml, which contains documentation for all namespaces, types, and type members (fields, methods, properties, etc.) for all standardized types.
What's actually covered? Enough to get the ball rolling -- I/O, XML, Reflection, Collections, Platform Invoke, etc. Basically, the.NET equivalent of the standard C library, and then some. (Well, much more than the standard C library, which lacks XML, Reflection, Collections.... But you get the drift.)
What isn't covered? Much more -- System.Windows.Forms, ASP.NET, ADO.NET, System.DirectoryServices, System.EnterpriseServices, etc. Much of this makes sense, as it doesn't already exist in a standardized form. Furthermore, much of it is specific to Microsoft Windows -- System.Windows.Forms is highly windows-specific, and will be "dropped" by Microsoft in favor of Avalon eventually, anyway. Other items have open-source equivalents -- LDAP can work for System.DirectoryServices.
To put it in perspective, ~295 classes are standardized, out of the ~7000 in.NET. (Number completely made up, but Mono has over 7000.cs files in CVS, and Mono hasn't fully covered.NET either. Of course, many of those classes aren't public, and thus couldn't be used by external developers, but the number should be in the neighborhood...)
Whether this is "bad" or not is outside the scope of this response.:-)
Copyrights aren't patents, and Fraunhofer owns several patents on the MP3 algorithms. It isn't possible to implement MP3 support without infringing their patents.
Something very similar to your example is possible with C# 2.0 anonymous delegates. Just substitute "yield" with a delegate invocation, and each Ruby anonymous block becomes an anonymous delegate.
using System;
class Test { delegate void Func ();
// make sure the lock is released in case of error private static object lock_ = new object (); static void WithLock (Func f) { lock (lock_) { f (); } }
// see how long the code took to run static TimeSpan TimeIt (Func f) { DateTime start = DateTime.Now; f (); return DateTime.Now - start; }
// run the test public static void Main () { TimeSpan s = TimeIt (delegate { WithLock (delegate { for (int i = 0; i != 3; ++i) { Console.WriteLine ("foo!"); Console.WriteLine ("bar!"); } }); Console.WriteLine ("xyz"); Console.WriteLine ("abc"); }); Console.WriteLine ("Operation took {0} seconds", s); } }
This is still present in Gnome 2, you just need to know about it. Set the GConf key:/desktop/gnome/interface/can_change_accels to TRUE, either via gconf-editor or the command-line:
Behavior is similar to GTK 1.x. The one restriction I've seen (and I'm not sure if it was present in GTK 1.x) is that you can't assign an accelerator that's already in use. For example, for Help-> About, 'A' is already in use as an accelerator, so you can't re-use 'A' in that menu.
Nautilus isn't faster because it's spatial. It's faster because it uses file extensions for MIME-type checking instead of file sniffing. This greatly increases performance, as the disk doesn't need to be accessed for every file in a directory. This is particularly noticable if your directory has thousands of files...
File sniffing is still used in two circumstances:
When the file lacks an extension, such as README or configure.
When the user opens the file. The sniffed MIME-type is compared to the file extension, and if there's a mismatch, Nautilus complains loudly. This is to help prevent trojans, such as a shell script named README.txt, which would imply being a text/plain MIME type but are actually application/x-shellscript.
In addition to to opening up a new window for every folder, the folders "cascade" so if you need to get somewhere fast, your screen slowly fills up with folders you have NO USE FOR.
The folders should cascade only once, the first time you ever open the folder. From that point onward, whenever you re-open that folder, it will appear in exactly the same screen location as the previous time it was closed. It will also retain the same window size, and window backgrounds (images, colors, etc) can also be per-folder (though how to do this isn't particularly well documented ATM). This is what "spatial" is about. So you'll only get a "cascade" of windows if you never bother to move the windows into a sensible location.
Put another way, if your windows are always cascading, it's your own falt! (Note "always"; the first time Nautilus opens a folder, the placement is at the discretion of the window manager.)
In addition, there is no location bar where you can "jump" to a place you want
Press Ctrl+L, and you'll get a dialog box that lets you jump to any place you want. It even supports file-name completion! This is also available as a menu item, though I forget what it is.
nor do you get a sense of where you are in the file system.
Please see this image:
nautilus-parentfolders.png. The "menu" in the lower-left corner of the window gives tells you precisely where you are on the filesystem, as it contains the full path of the folder. Furthermore, clicking on any of the menu entries will open the specified folder.
And good luck even if you do have a sense of where you are because there are no forward back or up buttons in sight to allow you to get anywhere (I know there is a hidden menu, but it's hidden, it may aswell be a keyboard shortcut for how easy it is to use from a GUI perspective).
I don't consider that menu to be hidden. It also lets you jump up to any parent directory, so this suffices (somewhat) as a "back" button.
All of this reeks of hijacking of the OS by some disgruntled designer, aka a former BeOS dude or whatever. I don't mind you making a BeOS style file browser dudes, but seriously.... make a fork of gnome.... don't just hijack gnome (at a 2.6 release, not some early design stage, a mature 2.6) to your own ends.
Spatial navigation has been around since the original Macintosh, and has a number of proponents. You might find this article useful. As for research, there has been lots of research done in the 80's, and spatial was the preferred approach. This is why "direct manipulation" is so prevalent in desktop environments today. Or have you never used Drag And Drop?
Microsoft has every right to build its products as it wishes.
Microsoft has every right to develop software as it wishes. It does not have every right to sell (or otherwise distribute) that product. For example, drug companies have every right to develop drugs; they don't have the right to sell those drugs until they've passed the FDA. Ditto for any other company, in any other field; regulation is everywhere.
I suppose you could argue that such regulations are anti-competitive and against capitalism. You may be right. But those are the rules we currently have, typically written to avoid the problems of unregulated capitalism (or do you not like knowing that the food you eat is relatively safe?).
In the case of Microsoft, they are convicted of having abused a monopoly, so they play under different rules than the rest of the software industry. Period. Microsoft has no right to sell software against EU regulations.
This is also why Apple and Linux can "get away with product bundling" -- they're not convicted of abusing a monopoly, so they play by different rules.
Patents do expire. They only last 20 years from the date of application. Which is still an eternity for the computer industry, but it's still for a limited time. Copyrights, on the other hand, look like they're set to last an eternity, since Congress keeps extending the lifetime of copyrights retroactively...
In fact, the patent situation has improved (somewhat) over the past decade. Previously, patents could remaind "hidden" for decades; Google for "Submarine Patents".
As someone else stated, it's a standard, not a product. The C# Standard merely describes the C# language.
Where are the APIs? That's a different standard. ECMA-335, to be precise, and it describes a set of APIs to program against, as well as what the intermediate language is, the semantics the the IL, how it should be executed... In short, most of what you would need to know in order to execute a.NET program.
The one downside is that ECMA-335 doesn't define the entire library to.NET; it's missing Windows Forms, ASP.NET, and other large parts of the library. But that doesn't prevent the developer community from re-implementing these libraries. In fact, people are working on these libraries as part of the Mono Project.
Slashdot Mirror
You're reading the chart wrong. The chart states that the iPhone 3G, released in June 2008, ran the current OS for three years after release, which is correct: the iPhone 3G was updated to iOS 4.2.1, which was released on November 22, 2010, and it continued to run the current major iOS 4.x series until iOS 5 was released in October 2011. (Granted, it stopped receiving updates in March 2011 with iOS 4.3, but that was still the same major version series.)
The iPhone 3GS, meanwhile, will likely get support for at least 4 years, given that Apple is still selling the iPhone 3GS and, historically, provides at least 2 years of support.
As for the Samsung Galaxy, which Galaxy? The Samsung i5500 is pre-loaded with Android v2.1, in the summer of 2011. That's 2 major releases behind!
The Samsung Galaxy S II, meanwhile, was shipped with Android v2.3, which is still the current version (4.0 hasn't shipped yet). It's rumored to be getting ICS, which is good, but previous Samsung phones were also promised to get updates...which never happened. So we'll need to wait-and-see.
My guess is approximately zero seconds, as Apple is sure to kill this.
Why would Apple want to kill this?
MonoTouch is not significantly different from Unity 3D, which has been used to create over 40 games for iPhone already.
The primary difference is, instead of needing to create user interfaces purely atop GL, you can use the CocoaTouch libraries and get native buttons, frames, html controls, etc.
Microsoft did rebuild Windows from the ground up as a modern operating system. That was Windows NT (as compared with Windows 3.0) back in 1993. Thus, they predated the "let's rebuild the OS from scratch" thing that Apple did by 8 years.
That said, even as a modern operating system, it has a number of anachronisms kept primarily for backward compatibility with legacy 16-bit code, and has even more backward compatibility "hacks" for poorly written 32-bit apps (see the oldnewthing archives -- lots of apps do stupid things), but their priority is keeping existing code working, instead of breaking existing (poorly written) apps. I can't fault them for this.
The only thing removing such anachronisms would do is prevent older programs from working, which really does no one any good (unless you like the thought of Microsoft shooting their own lower-torso off...)
Why not?
What's wrong with little endian? Aside from the fact that network-byte-order is big endian, I see nothing wrong with it. In fact, little endian has an advantage, at least in theory: arbitrary sized arithmetic. You could always add two numbers together, a byte at a time, check the carry flag, and then progress to the next byte, for *any* size number. This would allow trivial addition of multi-gigabyte numbers in very little assembly.
Lack of registers is largely rectified in AMD64/ie32e, in which 16 GP registers exist. Sure, it's not the 32 registers of PPC (or the 128 of Itanium), but it's sufficient for most code. It really doesn't matter anyway, since the CPUs keep track of dozens of registers internally as part of the internal register renaming system...
CISC? You must be kidding. Sure, the instruction set is CISC, but the internals of x86 CPUs have been RISC-like since the Pentium, with a hardware instruction decoder that converts legacy x86 instructions into internal RISC-like instructions. It's largely a non-issue today. (Yes, the hardware decoder takes up more die space, but it's a fixed size, and a constantly shrinking amount of die space as the dies keep getting bigger with Moore's law.) Plus, CISC acts as a sort of compression scheme, so that CISC programs are smaller than the equivalent RISC programs, resulting in lower memory pressure when loading/executing the code -- all good things when memory keeps getting slower and slower relative to the CPU.
There's really nothing fundamentally wrong with x86. If there were, it wouldn't be used as widely as it is (because if it were fundamental it couldn't be easily fixed).
Mono has had complete System.Windows.Forms 1.1 API support since Mono 1.2. System.Windows.Forms 2.0 is still being worked on, with the missing methods reported by MoMA getting implemented first.
Mono has many System.Data providers, including System.Data.Odbc, System.Data.OleDb, System.Data.OracleClient, and System.Data.SqlClient, though I can't say how complete these are. You will likely need to test your code.
Mono has had ASP.NET support for quite some time, as well as .NET Remoting, so ASP.NET web services (.asmx files) and .NET Remoting web services are both supported.
Apple has to charge different prices in different countries becuase Apple needs to license the music separately for each country, and the licensors in each country may want to charge different prices (and restrict what can be licensed!).
Consider books: you write a book, and it gets published. If some other publisher wants to sell your book in a different country, that publisher will need to talk to you (assuming you remain the copyright owner). However, it's quite likely that a different country will speak a different language, so your book will need to be translated, adding additional expense which the publisher will want to recoup. Result: the book in the other country costs more to purchase than just purchasing your original book + shipping it.
"But this adds translation charges, which aren't at issue here!" True, but translations aren't the only source of additional fees. The countries copyright association may require blanket fees in order to handle copyright infringement (consider blank media -- CD-Rs, tapes, etc. -- which includes such hidden fees), and this will need to be handled by all licenses.
Summary: Apple (probably) can't set a worldwide price because it (probably) can't get licenses which would permit a single worldwide price.
Wine is most certainly a reverse engineering effort. The problem is that you don't fully understand what reverse engineering includes.
Reverse engineering also includes the following process:
This is black box reverse engineering. You treat some piece of software as a block box, write tests for it, figure out what the "box" is doing, and recreate that behavior. No decompilation required, no source code required, just lots of tests and ingenuity. This has the benefit that no copyright violations are required (since you never decompile the original program). This process is also used in clean room design, except step 3 is replaced with a documentation step -- instead of code being the result of the process a specification is the result. Compaq did this to reverse-engineer the IBM PC BIOS.
Wine is most certainly doing this, as it's the only way to determine undocumented connections between various APIs. Mono certainly does this ("what's this member supposed to do, and is Mono's version following that behavior properly?"). Another way to think of this is for bugs -- does this Mono code do what the .NET equivalent code does? If not, we'll get a bugzilla entry for it, and (eventually) fix it. This bug-report/fix cycle can also be considered as black box reverse engineering, since the bug-report is itself a test, through which we can determine what the actual functionality should be.
Decompilation is generally not legal, since it can lead to copyright violations. Black box reverse engineering is legal, and any attempt to limit black box reverse engineering would kill the interoperability market, since no compatible hardware/software could ever be created unless the original manufacturer permitted it.
Don't contributors assign copyright to some type of Linux foundation?
No. Linux kernel contributors retain their own copyright. This is frequently considered to be a good thing, as it means that no single group has copyright over everything, which means that no single group can change the license to e.g. BSD and start selling a proprietary version of Linux.
what then happens 17-20 years later, when all the patents expire? ... [T]here are lots of parties who depend on expired patents for their businesses (generic drugs, eg) so there would be a strong lobby against that for a change.
You'd like to think that, but you'd be wrong. Yes, there are people who would lobby for the patents expiring, but their lobbying would be useless. In the drug world, patents do indeed expire. And the still can't be manufactured generically because the drug companies file a new patent combining the generic drug with another (potentially generic) drug, selling them as a combined unit. For bizarro reasons, this prevents the original drug from being freely reusable.
So for story line patents, when a patent expires, a new patent will be filed combining the expired patent with a new idea, creating a new patent, thus perpetuating the problem. Fun for all involved!
Actually, this is exactly the case. Houses in California cost $500,000 (or more!) for something that would cost $200,000 (or less!) in Rochester, NY (never mind West Virginia). That's also why we have Cost of Living calculators, to better compare our current salary to what we'd need to live equivalently elsewhere (due to food, gas, rent, mortgage, dining...); for example if you earn $50,000 in Bluefield, WV, you would need to make $134,050 in Menlo Park, CA to have an equivalant lifestyle.
This isn't a "new era" of "geo-discrimination," this has always been the case (though it has gotten worse as the housing bubble gets larger).
There may not be a Microsoft .NET Framework for Unix or Linux, but there is a (largely) .NET-compatible implementation in Mono.
Mono isn't 100% compatible with all of .NET, and may never be (infrequently used parts haven't been implemented, such as System.EnterpriseServices, System.Messaging, COM Interop, etc.), but what it does provide is an implementation of the underlying ECMA standards (for C# and for the Common Language Infrastructure), plus an effort for .NET compatibility in all that is reasonable (I/O, XML, app configuration, ASP.NET support via XSP and mod_mono, Database access, and more). Initial support for System.Windows.Forms is planned for the next release, 1.2, due around September.
Mono also provides it's own extensions, such as a GTK+ binding (Gtk#) and Unix-integration libraries.
Mono is already useful and in use.
Now, I'm not saying that any piece of .NET software will be able to run unchanged under Mono. In general, this isn't possible as it could rely on Windows-specific functionality, such as COM Interop, or rely on Windows-specific libraries. I am saying that Mono provides a portable base to build software upon, much as the ANSI C and the POSIX.1 standards do. You can write portable software, but you are not required to do so. Guidelines for writing portable .NET code can be found in the book Cross-Platform .NET.
The JIT isn't the issue. The intermediate language is, or rather was, the issue. When Mono was started, GCC used a register-based intermediate language. It is difficult to translate a register-based intermediate language to a stack-based intermediate language.
Look at the GCC/Java backend, which skips the entire register-based intermediate layer; the GCC/Java project basically re-wrote the GCC back-end to avoid the register layer. Because of this, you couldn't compile any GCC-supported language to Java bytecode, such as C, C++, FORTRAN, Ada, because they all targeted the register IL instead of Java's stack-based IL.
See also: Mono's Technical FAQ.
Things are somewhat different as of GCC 4, due to the GIMPLE architecture which should support stack-based architectures such as Java bytecode and CIL. However, GCC 4 didn't exist when Mono was started (it doesn't exist now, except in beta form), so it obviously couldn't be used as part of Mono.
I can't speak to the truth of this, but I can say that I haven't seen any comments from GCC developers on the mono mailing lists regarding the SSAPRE algorithms. I can't think of any messages from a GCC developer on the mono lists, actually...
Another backend was necessary because CIL and Java bytecode are different. Differences are outside the scope of this, but one difference is whether or not types are part of the opcodes -- compare Java's iadd, ladd, fadd, dadd to CIL's add opcode. Generics add a further difference -- compare Java's type erasure to the "baked-in" generics support of CIL.
To support CIL at all, you need to support another backend, just to support the differences between Java bytecode and CIL. Alternatively, you can argue that CIL shouldn't be supported, which would tie .NET developers to Windows without any chance of migrating to another platform.
There is little doubt that Free- and open-source software infringes someone's patents. To some extent this has been covered before; see older slashdot stories. Then you have the random patents such as the JPEG patents (thought JPEG was patent-free? ha!). MPEG is also covered by several patents. Just because there hasn't been a lawsuit doesn't mean that patents aren't present.
There is little doubt that closed-source software infringes someone's patents; see all the lawsuits against Microsoft, Sun, and anyone else of consequence.
You want to see the violations? Really? Are you sure?
I ask because if you know about a patent and then try to work around it, if you're found infringing you're subject to treble damages. It's far better to live in ignorance and not know what patents you're potentially infringing; that way you're only subject to 1x damages, not 3x, and that's only if you lose the patent case. Linux Torvalds has said as much several times.
This is why the software patent situation is so crazy: everything is covered. Anything and everything, no matter how trivial, has either been patented or will be patented; it's only a matter of time.
Which is why it doesn't matter if PHB's think that Linux is risky, as long as they realize that everything is risky. Patents are just a shell game to keep independant developers down; only big business -- or patent shell companies -- gain in this climate.
One minor question: How do we debug this? :-)
The nice thing about plain text (ASCII) is that I can open it in an editor and read it, without worrying that my editor may be screwing things up. I can't do that with Binary XML.
If we did as you propose, I couldn't easily examine the output of my program. I'd instead have to load the output of my program in Super Notepad to view the output. And if my Binary XML functions are buggy? Super Notepad is no longer a help. So what do I do? Start adding print statements to get plain text output back, allowing me to understand what's actually happening. (Sure, I could use a debugger too, but I need some context to find where the bug is, so I'll need ASCII output at some point...)
The last thing I need is yet another layer of binary madness between me and the data I'm trying to interpret. That way lies madness.
In contrast to all the other responses (discussing signal propogation time and other issues), here's a different observation:
This has already happened (somewhat), and is continuing to happen.
How so? Adding additional integer and floating point units increases the processor size and performance. As does better branch prediction code. As does Level 1 Cache.
Then there are the modern marvels such as SMT (aka HyperThreading), or even putting multiple cores onto the same die (see IBM's POWER series, and AMD and Intel will be doing this too).
The key point of Herb Sutters article is that CPUs will continue to advance (more CPU cores, better HyperThreading, more Cache), will continue to get bigger, but all these advances won't be increasing MHz. Consequently, none of these advances will help single-threaded code. Concurrency is the only way to increase performance now.
My apologies for the horrible look of the code samples. Slashdot won't let me use nice, short lines, as it results in lines which are too short. Gah! Apparently I need ~40 characters per line (average) to get past the @#$% filter... This has to be the most annoying filter I've ever come across; I've spent more time getting past the filter than responding to your question!
Iterators are similar to java.util.Iterator. C# iterators are compiler support for implementing the System.Collections.IEnumerator interface. For example, in Java you'd write:
C# iterators make this much easier:
C# iterators are particularly useful when implementing your own collection objects. Google for them; they're very powerful.
Anonymous Methods are methods without a name, just like Java anonymous classes are classes without a name. Same basic idea, fewer braces. They also act as full closures; while Java requires that all stack variables referenced from an anonymous class be final, C# doesn't require this.
The above example is bad, but you can let your imagination run wild. This is very useful for event handlers.
Partial Types
allow you to split a single class definition across multiple files. This is useful to prevent > 50 KB source files (yech!), and makes it easier to have part of a class machine generated (by a GUI builder) and part hand-written. Some people hate it, others are ambivalent, but it can be handy:
Nullable types are primarily useful for database support in the .NET type system. DB types can be "nullable" -- not present. For reference types, this is easy -- use null. For .NET value types, this isn't possible, as value types can't be null. The solution is to introduce a generic class System.Nullable<T>, which can wrap value types such as int.
The C# compiler adds syntactic sugar to this, to simplify usage:
Nullable types are more special purpose, but are useful for those who need them.
Ignore the rest of this: it's just garbage to get past Slashdot's wonderful "too few characters per line" problem: lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja the quick brown fox jumps over the lazy dog l;kajdsfl;kj;lkj l;kjasdilfj l;kjoiewqruq[op 0-9314u75 lkfjx ;lkajdsfmopiac un0p3u5n1-0329u kl 0a9u 3214o5ilj hello out there in tv land! q 09
Which class libraries? :-)
ECMA-335, which the grand-parent referenced, standardizes some of the class libraries. In particular, this file contains All.xml, which contains documentation for all namespaces, types, and type members (fields, methods, properties, etc.) for all standardized types.
What's actually covered? Enough to get the ball rolling -- I/O, XML, Reflection, Collections, Platform Invoke, etc. Basically, the .NET equivalent of the standard C library, and then some. (Well, much more than the standard C library, which lacks XML, Reflection, Collections.... But you get the drift.)
What isn't covered? Much more -- System.Windows.Forms, ASP.NET, ADO.NET, System.DirectoryServices, System.EnterpriseServices, etc. Much of this makes sense, as it doesn't already exist in a standardized form. Furthermore, much of it is specific to Microsoft Windows -- System.Windows.Forms is highly windows-specific, and will be "dropped" by Microsoft in favor of Avalon eventually, anyway. Other items have open-source equivalents -- LDAP can work for System.DirectoryServices.
To put it in perspective, ~295 classes are standardized, out of the ~7000 in .NET. (Number completely made up, but Mono has over 7000 .cs files in CVS, and Mono hasn't fully covered .NET either. Of course, many of those classes aren't public, and thus couldn't be used by external developers, but the number should be in the neighborhood...)
Whether this is "bad" or not is outside the scope of this response. :-)
Copyrights aren't patents, and Fraunhofer owns several patents on the MP3 algorithms. It isn't possible to implement MP3 support without infringing their patents.
- Jon
Something very similar to your example is possible with C# 2.0 anonymous delegates. Just substitute "yield" with a delegate invocation, and each Ruby anonymous block becomes an anonymous delegate.
// make sure the lock is released in case of error
// see how long the code took to run
// run the test
using System;
class Test {
delegate void Func ();
private static object lock_ = new object ();
static void WithLock (Func f) {
lock (lock_) {
f ();
}
}
static TimeSpan TimeIt (Func f) {
DateTime start = DateTime.Now;
f ();
return DateTime.Now - start;
}
public static void Main () {
TimeSpan s = TimeIt (delegate {
WithLock (delegate {
for (int i = 0; i != 3; ++i) {
Console.WriteLine ("foo!");
Console.WriteLine ("bar!");
}
});
Console.WriteLine ("xyz");
Console.WriteLine ("abc");
});
Console.WriteLine ("Operation took {0} seconds", s);
}
}
This is still present in Gnome 2, you just need to know about it. Set the GConf key: /desktop/gnome/interface/can_change_accels to TRUE, either via gconf-editor or the command-line :
Behavior is similar to GTK 1.x. The one restriction I've seen (and I'm not sure if it was present in GTK 1.x) is that you can't assign an accelerator that's already in use. For example, for Help-> About, 'A' is already in use as an accelerator, so you can't re-use 'A' in that menu.
Nautilus isn't faster because it's spatial. It's faster because it uses file extensions for MIME-type checking instead of file sniffing. This greatly increases performance, as the disk doesn't need to be accessed for every file in a directory. This is particularly noticable if your directory has thousands of files...
File sniffing is still used in two circumstances:
The folders should cascade only once, the first time you ever open the folder. From that point onward, whenever you re-open that folder, it will appear in exactly the same screen location as the previous time it was closed. It will also retain the same window size, and window backgrounds (images, colors, etc) can also be per-folder (though how to do this isn't particularly well documented ATM). This is what "spatial" is about. So you'll only get a "cascade" of windows if you never bother to move the windows into a sensible location.
Put another way, if your windows are always cascading, it's your own falt! (Note "always"; the first time Nautilus opens a folder, the placement is at the discretion of the window manager.)
Press Ctrl+L, and you'll get a dialog box that lets you jump to any place you want. It even supports file-name completion! This is also available as a menu item, though I forget what it is.
Please see this image: nautilus-parentfolders.png. The "menu" in the lower-left corner of the window gives tells you precisely where you are on the filesystem, as it contains the full path of the folder. Furthermore, clicking on any of the menu entries will open the specified folder.
I don't consider that menu to be hidden. It also lets you jump up to any parent directory, so this suffices (somewhat) as a "back" button.
Spatial navigation has been around since the original Macintosh, and has a number of proponents. You might find this article useful. As for research, there has been lots of research done in the 80's, and spatial was the preferred approach. This is why "direct manipulation" is so prevalent in desktop environments today. Or have you never used Drag And Drop?
Microsoft has every right to develop software as it wishes. It does not have every right to sell (or otherwise distribute) that product. For example, drug companies have every right to develop drugs; they don't have the right to sell those drugs until they've passed the FDA. Ditto for any other company, in any other field; regulation is everywhere.
I suppose you could argue that such regulations are anti-competitive and against capitalism. You may be right. But those are the rules we currently have, typically written to avoid the problems of unregulated capitalism (or do you not like knowing that the food you eat is relatively safe?).
In the case of Microsoft, they are convicted of having abused a monopoly, so they play under different rules than the rest of the software industry. Period. Microsoft has no right to sell software against EU regulations.
This is also why Apple and Linux can "get away with product bundling" -- they're not convicted of abusing a monopoly, so they play by different rules.
Patents do expire. They only last 20 years from the date of application. Which is still an eternity for the computer industry, but it's still for a limited time. Copyrights, on the other hand, look like they're set to last an eternity, since Congress keeps extending the lifetime of copyrights retroactively...
In fact, the patent situation has improved (somewhat) over the past decade. Previously, patents could remaind "hidden" for decades; Google for "Submarine Patents".
As someone else stated, it's a standard, not a product. The C# Standard merely describes the C# language.
Where are the APIs? That's a different standard. ECMA-335, to be precise, and it describes a set of APIs to program against, as well as what the intermediate language is, the semantics the the IL, how it should be executed... In short, most of what you would need to know in order to execute a .NET program.
The one downside is that ECMA-335 doesn't define the entire library to .NET; it's missing Windows Forms, ASP.NET, and other large parts of the library. But that doesn't prevent the developer community from re-implementing these libraries. In fact, people are working on these libraries as part of the Mono Project.
- Jon