We did create unwritable registry keys and file names, by exploiting an "impedance mismatch" between the Win32 API and the NT API. Windows, ever since XP, is fundamentally built on top of the NT kernel. NT is fundamentally a Unicode system, so all the strings internally are 16-bit counter Unicode. The Win32 API is fundamentally Ascii. There are strings that you can express in 16-bit counted Unicode that you can't express in ASCII. Most notably, you can have things with a Null in the middle of it.
The interviewee's explanation is a bit misleading; that has nothing to do with Unicode vs. ASCII, that has to do with counted strings vs. null-terminated strings. One can have counted ASCII strings and one can have null-terminated Unicode strings - for example, the, err, umm, Win32 API has null-terminated Unicode strings if the Unicode version is used (it has both ASCII and Unicode versions). If, for example, the UNICODE_STRING type in Windows were an array of 16-bit Unicode characters with a null at the end of the array, rather than a structure with two length values and a pointer to the string buffer, and the Windows Registry were the same as it is now, the NT API would be Unicode but you wouldn't be able to create registry keys with a null in the middle, so you'd still have the Registry but this particular problem wouldn't exist.
(I'm not saying whether the Registry is a good or a bad idea. I'm just saying that this problem doesn't demonstrate that it's a bad idea; it demonstrates that, if you don't consider inaccessible names to be a feature, you need to be careful if there are both APIs with counted-string names and APIs with null-terminated-string names - have the counted-string APIs reject names with nulls in the middle.
Consider NFS, for example - strings in ONC RPC's XDR are counted, so file names that go over the wire in NFS are counted, but, at least on UN*X systems, the APIs to access files by name use null-terminated strings, so when a server gets an NFS request to create files/directories/links etc. it might be a good idea to have it reject the request if the file name has an embedded null in it. And, yes, I've fixed at least one NFS server to do exactly that....)
The problem wasn't with the code that determined whether a year is a leap year or not (which was correct, and was using the same algorithm as your FORTRAN example). The problem was with the loop, and somebody could've made the same error in FORTRAN 66.
Unlocking an iPhone has nothing to do with that. To quote the introduction to the article:
They've finally figured out a way to get the phone to work with any cell phone carrier (and not just AT&T). The iPhone Dev Team is best known for their work on 'jailbreaking;' the technique of altering an iPhone so that you can run any applications on it, not just those approved by Apple.
"Finally, I can use Opera Mini on my iPhone" would be a response to jailbreaking an iPhone, not to unlocking one.
Yup - they figured out how to design a calendar system that would provoke all sorts of speculation and running around in circles in the future.. I nominate the Mayan calendar system for "best troll ever!"
You're god-damned right we are. If there's anything about America that the rest of the world hasn't learned, its that we don't like being told what to do.
Especially when told to use logic and facts to form opinions than to just obtain them ex recto.
AT&T for a long time didn't own the phone network. It did at first, but then the infrastructure was nationalized in the interests of 'national security'. Read the link I provided.
The relevant quote is
In 1918 the federal government nationalized the entire telecommunications industry, with national security as the stated intent. Rates were regulated so that customers in large cities would pay higher rates to subsidize those in more remote areas. Vail was appointed to manage the telephone system with AT&T being paid a percentage of the telephone revenues. AT&T profited well from the nationalization arrangement which ended a year later.
In 1918, President Wilson nationalized the U.S. phone network, promising that rates would fall under public control. However, expenses related to wartime activities prompted AT&T to raise prices, and U.S. citizens began calling for the government to release control of the phone system. By then, AT&T operated a network of roughly 10 million telephones. Mounting public pressure prompted the government to privatize AT&T in 1919.
An operating system with the name "AIX" was available on x86, just as an operating system with the name "AIX" was available on IBM mainframes. I don't think those two operating systems with the name "AIX" were the same as each other or as the operating system with the name "AIX" that runs on POWER/PowerPC/Power Architecture hardware.
Solaris (and previously SunOS) were Sun's implementation of UNIX. Right, just like Linux and FreeBSD.
Although, unlike Linux, it was originally based on a lot of AT&T code; whether they replaced, or got the rights to redistribute in source form, as much of that code as CSRG and the Regents of the University of California did is another matter.
(I.e., Sun didn't create SunOS 1.x-4.1.4, or SunOS 5.x, from scratch.)
Ever heard of SUS ? SYS V ?
Yes, I've heard of System V, and a lot of the code in Solaris 2.0, at least, came from it. Of course, a lot of the code in System V Release 4 came from, err, umm, Sun, so Sun presumably had less trouble getting that code open-sourced.
They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager. And it's a very young project with a lot of FIXMEs and hand waving.
and
The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the NOTES file of the project.
I'm actually pretty sure WinMo isn't the most common smartphone platform - that distinction probably goes to RIM, and if not then S60. But Nokia has a much smaller presence in the US than in Europe and Asia. I'm pretty sure RIM has the most smartphones overall.
Gartner's Q2 2008 worldwide statistics by OS put Symbian first, followed by RIM, followed by Windows Mobile, followed by Linux, followed by Mac OS X^W^W^WiPhone OS.
Apple determines what software is allowable on the iPhone, and most of the apps on it are for entertainment purposes or is garbage.
So what are the statistics for other platforms? My-Symbian.com's list of Series 60 apps has the most apps in the, err, umm, "Games and Entertainment" category, followed by "Miscellaneous Utilties", followed by "Graphics & Multimedia".
Browsing Microsoft's Windows Mobile Catalog shows, by far, the most apps in, well, "Games and Entertainment", followed by "Business and Office Productivity".
The main use for the thing, as admitted by Apple, is to basically have an iPod phone that delivers your need for both a cell phone and a music/video device.
I have used many applications that require you enter pathnames - for example, Native Instruments' music apps, which need you enter a path to a sample library, or to other necessary components which the software won't run without. A lot of Unix/Windows apps ported or cross-developed in this way seem to think paths are a pretty neat idea. You NEVER saw that on classic Mac OS.
Oh, good grief - Wireshark is currently mostly "just a UN*X app" on OS X (it does know about OS X when, for example, opening a browser with a given URL, just as it knows about Windows), using GTK+ (on X11, not on Quartz, by default) as its toolkit, and it doesn't require you to type pathnames to open capture files (some preference settings require you to type pathnames, but that's just because nobody's gotten around to implementing "pathname" as a preference type, with a "browse" button; it's been on my TODO list for ages).
If Native Instruments' apps are, well, "native", that's just broken; they don't even have a "browse" button to let you use the Open dialog to select a component name? (Hell, they shouldn't even require that on WIndows! The same applies for UN*X+X11 apps ported to OS X.)
Backwards compatibility - as it's a UN*X, the pathname separator at the lowest API layer in Mac OS X is slash, but the pathname separator in classic Mac OS was colon, and people may have had files with names with slashes in them, so....
Yes, but Macs don't use standard Unix filesystems by default - they use HFS+. The correct solution is to implement a filesystem that allows filenames to contain slashes, yet handles Unix paths correctly.
No, the correct solution is to support multiple file systems (HFS+, ZFS, ISO 9660, {V}FAT, NFS, AFP, SMB, etc., etc., etc., in a way that lets applications care as little as possible what particular file system they're running on, just as every other UN*X does; strangely enough, that's what Mac OS X does.
This means the fact that Macs use HFS+ as their local file system by default - which is not necessarily guaranteed to be true forever - is irrelevant; OS X is a UN*X, so the pathname separator at the lowest level is a slash, and that's not going to change (especially with Leopard getting certification as being a UNIX, not just a UN*X).
The "cleanest" situation would be to have the GUI allow colons in file names and not allow slashes in file names, and not try to hide the UN*Xness from the user. For better or worse, it was, I guess, decided that this wasn't going to fly with Mac users, so they chose to map slashes to colons. I could see that, for better or worse, the "it's a UN*X, deal" solution wouldn't have flied with traditional Mac users....
How can it be done? I don't know... but I do know that the solution they came up with is very hackish and un-Maclike.
Perhaps, for better or worse, their "hackish and un-Maclike" solution was the best compromise available. If you think it could be done better, prove you're right by showing how, rather than by wimping out with "I don't know...".
Interestingly, giving the user the option of hiding filename extensions is a worse idea than just leaving them hidden or showing full-time!
Frankly, I like the Konqueror (and Nautilus?) solution - don't require extensions to identify file types if the type can be inferred from the file contents, but also don't depend on the file system supporting metadata such as type/creator codes. It worked pretty well for me - I just, for example, just removed the ".pdf" from the names of PDF files. When I switched to a Mac, I had to add ".pdf" back for all the protocol specs, etc. that I had, which was a bit of an irritation.
So where do you have to type pathnames in OS X (other than after those funny strings ending with "$" or "%" in that funny "Terminal" application)?
and compounded the problem by implementing the silly colon-to-slash-to-colon conversion on the fly
Backwards compatibility - as it's a UN*X, the pathname separator at the lowest API layer in Mac OS X is slash, but the pathname separator in classic Mac OS was colon, and people may have had files with names with slashes in them, so.... (Yes, there's another such conversion in HFS+, in the opposite direction, so that classic Mac OS and OS X could share HFS+ volumes.)
along with hiding filename extensions...
You can control whether you want that (in Leopard, in the "Advanced" pane of the Finder preferences, select "Show all file extensions"; that might be where it's set in earlier releases). You can also control it on a per-file basis.
I tend to like it, as the icon for a file tells me what it is. (In FreeBSD+KDE, I often didn't need the extension in the file, as file typing was done by looking at file contents.)
Um, are you talking about Interface Builder, which is used for both OSX and iPhone SDKs?
...and used to Build somewhat different Interfaces, given that the screen sizes, input methods, etc. are different on small handhelds than on desktops/laptops.
Of course it is not *exactly* the same in terms of the interface and some hardware specific calls, but the core code for the kernel is *essentially* the same.
If by "the kernel" you mean XNU, that may be the case, but it's no more the case that it's a "twofer" because the kernel is the same than that developing for, say, GNOME+Linux desktops and a (hypothetical) GNOME+Linux-based phone would be a "twofer" because the kernel is the same. The input mechanisms in the UI are very different, the screen size is very different, etc., so, although you could still use open() to open files, read() to read them, etc., you can't assume that you have, for example, a big screen on which to display what you read, a keyboard convenient for lots and lots of typing, etc..
The MVC/KVC models are the same. Sorry, but if you can't design your UI to be intuitive, that not a limitation of Interface Builder but your inability to design to the iPhone/iTouch form factor.
Designing to the iPhone/iPod Touch form factor isn't the same as designing to the desktop/laptop form factor. So, no, it's not a twofer.
I don't know about everyone else here, but from reading TFOP, it looks like he's working for a housing developer trying to build a house that can be controlled from the client's phone (it's not clear whether they are building for a specific client or attempting to sell, but it's irrelevant). As such, the iPhone (or iPod Touch) is the worst possible platform, as the idea is clearly to provide a specific application for one client, and Apple's distribution methods simply do not allow for it.
The Standard and Enterprise Programs allow you to share your application with up to 100 other iPhone or iPod touch users with Ad Hoc distribution. Share your application through email or by posting it to a web site or server.
Presumably you can also just slap the application on your phone and not share it.
Slashdot Mirror
*cough* There are more Fedora users than Ubuntu users. *cough*
*cough*The default desktop environment for Fedora is GNOME*cough*
From the interview:
The interviewee's explanation is a bit misleading; that has nothing to do with Unicode vs. ASCII, that has to do with counted strings vs. null-terminated strings. One can have counted ASCII strings and one can have null-terminated Unicode strings - for example, the, err, umm, Win32 API has null-terminated Unicode strings if the Unicode version is used (it has both ASCII and Unicode versions). If, for example, the UNICODE_STRING type in Windows were an array of 16-bit Unicode characters with a null at the end of the array, rather than a structure with two length values and a pointer to the string buffer, and the Windows Registry were the same as it is now, the NT API would be Unicode but you wouldn't be able to create registry keys with a null in the middle, so you'd still have the Registry but this particular problem wouldn't exist.
(I'm not saying whether the Registry is a good or a bad idea. I'm just saying that this problem doesn't demonstrate that it's a bad idea; it demonstrates that, if you don't consider inaccessible names to be a feature, you need to be careful if there are both APIs with counted-string names and APIs with null-terminated-string names - have the counted-string APIs reject names with nulls in the middle.
Consider NFS, for example - strings in ONC RPC's XDR are counted, so file names that go over the wire in NFS are counted, but, at least on UN*X systems, the APIs to access files by name use null-terminated strings, so when a server gets an NFS request to create files/directories/links etc. it might be a good idea to have it reject the request if the file name has an embedded null in it. And, yes, I've fixed at least one NFS server to do exactly that....)
The problem wasn't with the code that determined whether a year is a leap year or not (which was correct, and was using the same algorithm as your FORTRAN example). The problem was with the loop, and somebody could've made the same error in FORTRAN 66.
I can use Opera Mini on my iPhone.
Unlocking an iPhone has nothing to do with that. To quote the introduction to the article:
They've finally figured out a way to get the phone to work with any cell phone carrier (and not just AT&T). The iPhone Dev Team is best known for their work on 'jailbreaking;' the technique of altering an iPhone so that you can run any applications on it, not just those approved by Apple.
"Finally, I can use Opera Mini on my iPhone" would be a response to jailbreaking an iPhone, not to unlocking one.
Thank you for cut-and-pasting.
Those Mayans were a smart bunch.
Yup - they figured out how to design a calendar system that would provoke all sorts of speculation and running around in circles in the future.. I nominate the Mayan calendar system for "best troll ever!"
You're god-damned right we are. If there's anything about America that the rest of the world hasn't learned, its that we don't like being told what to do.
Especially when told to use logic and facts to form opinions than to just obtain them ex recto.
So somebody at Apple finally discovered SIMH, which has been running on other UNIX systems (and Windows) for many years.
Amit Singh is at Google, not Apple, and people have probably run SIMH on OS X before.
But, yes, there's nothing magical you have to do to "somehow" run PDP-11 binaries on OS X.
... as long as it's not Windows.
Wrong.
I've NEVER heard that interpretation before or ever considered it myself... are you sure it's not just you?
No, it's not just him (unless that was posted by Jon Stewart).
AT&T for a long time didn't own the phone network. It did at first, but then the infrastructure was nationalized in the interests of 'national security'. Read the link I provided.
The relevant quote is
In 1918 the federal government nationalized the entire telecommunications industry, with national security as the stated intent. Rates were regulated so that customers in large cities would pay higher rates to subsidize those in more remote areas. Vail was appointed to manage the telephone system with AT&T being paid a percentage of the telephone revenues. AT&T profited well from the nationalization arrangement which ended a year later.
Some other sources are AT&T Corp - Early History from the "Free Encyclopedia of Ecommerce":
In 1918, President Wilson nationalized the U.S. phone network, promising that rates would fall under public control. However, expenses related to wartime activities prompted AT&T to raise prices, and U.S. citizens began calling for the government to release control of the phone system. By then, AT&T operated a network of roughly 10 million telephones. Mounting public pressure prompted the government to privatize AT&T in 1919.
(Google for
nationalized phone 1918 at&t
to find more.)
AIX was available on x86.
An operating system with the name "AIX" was available on x86, just as an operating system with the name "AIX" was available on IBM mainframes. I don't think those two operating systems with the name "AIX" were the same as each other or as the operating system with the name "AIX" that runs on POWER/PowerPC/Power Architecture hardware.
Kerberos for authentication, encrypted traffic, lower overhead, no passwords or password hashes sent -- ever.
Kerberos authentication, encrypted traffic, and "no passwords sent" apply also to NFSv2 and NFSv3; that's all done at the ONC RPC layer.
And all of those are supported by Leopard's NFSv2 and NFSv3 (krb5 = Kerberos 5 for authentication; krb5i = Kerberos 5 with a signature for integrity checking; krb5p = Kerberos 5 with encryption for privacy).
Solaris (and previously SunOS) were Sun's implementation of UNIX. Right, just like Linux and FreeBSD.
Although, unlike Linux, it was originally based on a lot of AT&T code; whether they replaced, or got the rights to redistribute in source form, as much of that code as CSRG and the Regents of the University of California did is another matter.
(I.e., Sun didn't create SunOS 1.x-4.1.4, or SunOS 5.x, from scratch.)
Ever heard of SUS ? SYS V ?
Yes, I've heard of System V, and a lot of the code in Solaris 2.0, at least, came from it. Of course, a lot of the code in System V Release 4 came from, err, umm, Sun, so Sun presumably had less trouble getting that code open-sourced.
The 3rd please. The 1st wasn't president, but he was George Prescott Bush, making GWB a "3rd" :D
I know of no "George Prescott Bush". I know of a Prescott Sheldon Bush, father of George Herbert Walker Bush; George Herbert Walker Bush was, in turn, father of George Walker Bush.
To quote Kristian Hogsberg's blog:
They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager. And it's a very young project with a lot of FIXMEs and hand waving.
and
The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the NOTES file of the project.
I'm actually pretty sure WinMo isn't the most common smartphone platform - that distinction probably goes to RIM, and if not then S60. But Nokia has a much smaller presence in the US than in Europe and Asia. I'm pretty sure RIM has the most smartphones overall.
Gartner's Q2 2008 worldwide statistics by OS put Symbian first, followed by RIM, followed by Windows Mobile, followed by Linux, followed by Mac OS X^W^W^WiPhone OS.
Synergy Research's first-half 2008 US smartphone figures put RIM at the top (46%), Apple second (15%), Motorola third (presumably for all OSes).
Apple determines what software is allowable on the iPhone, and most of the apps on it are for entertainment purposes or is garbage.
So what are the statistics for other platforms? My-Symbian.com's list of Series 60 apps has the most apps in the, err, umm, "Games and Entertainment" category, followed by "Miscellaneous Utilties", followed by "Graphics & Multimedia".
Browsing Microsoft's Windows Mobile Catalog shows, by far, the most apps in, well, "Games and Entertainment", followed by "Business and Office Productivity".
The main use for the thing, as admitted by Apple, is to basically have an iPod phone that delivers your need for both a cell phone and a music/video device.
Citation for that admission, please?
I have used many applications that require you enter pathnames - for example, Native Instruments' music apps, which need you enter a path to a sample library, or to other necessary components which the software won't run without. A lot of Unix/Windows apps ported or cross-developed in this way seem to think paths are a pretty neat idea. You NEVER saw that on classic Mac OS.
Oh, good grief - Wireshark is currently mostly "just a UN*X app" on OS X (it does know about OS X when, for example, opening a browser with a given URL, just as it knows about Windows), using GTK+ (on X11, not on Quartz, by default) as its toolkit, and it doesn't require you to type pathnames to open capture files (some preference settings require you to type pathnames, but that's just because nobody's gotten around to implementing "pathname" as a preference type, with a "browse" button; it's been on my TODO list for ages).
If Native Instruments' apps are, well, "native", that's just broken; they don't even have a "browse" button to let you use the Open dialog to select a component name? (Hell, they shouldn't even require that on WIndows! The same applies for UN*X+X11 apps ported to OS X.)
Yes, but Macs don't use standard Unix filesystems by default - they use HFS+. The correct solution is to implement a filesystem that allows filenames to contain slashes, yet handles Unix paths correctly.
No, the correct solution is to support multiple file systems (HFS+, ZFS, ISO 9660, {V}FAT, NFS, AFP, SMB, etc., etc., etc., in a way that lets applications care as little as possible what particular file system they're running on, just as every other UN*X does; strangely enough, that's what Mac OS X does.
This means the fact that Macs use HFS+ as their local file system by default - which is not necessarily guaranteed to be true forever - is irrelevant; OS X is a UN*X, so the pathname separator at the lowest level is a slash, and that's not going to change (especially with Leopard getting certification as being a UNIX, not just a UN*X).
The "cleanest" situation would be to have the GUI allow colons in file names and not allow slashes in file names, and not try to hide the UN*Xness from the user. For better or worse, it was, I guess, decided that this wasn't going to fly with Mac users, so they chose to map slashes to colons. I could see that, for better or worse, the "it's a UN*X, deal" solution wouldn't have flied with traditional Mac users....
How can it be done? I don't know... but I do know that the solution they came up with is very hackish and un-Maclike.
Perhaps, for better or worse, their "hackish and un-Maclike" solution was the best compromise available. If you think it could be done better, prove you're right by showing how, rather than by wimping out with "I don't know...".
Interestingly, giving the user the option of hiding filename extensions is a worse idea than just leaving them hidden or showing full-time!
Frankly, I like the Konqueror (and Nautilus?) solution - don't require extensions to identify file types if the type can be inferred from the file contents, but also don't depend on the file system supporting metadata such as type/creator codes. It worked pretty well for me - I just, for example, just removed the ".pdf" from the names of PDF files. When I switched to a Mac, I had to add ".pdf" back for all the protocol specs, etc. that I had, which was a bit of an irritation.
On OS X, I compensate by hiding suffixes whe
Of course, Mac OS X threw out that little lesson
So where do you have to type pathnames in OS X (other than after those funny strings ending with "$" or "%" in that funny "Terminal" application)?
and compounded the problem by implementing the silly colon-to-slash-to-colon conversion on the fly
Backwards compatibility - as it's a UN*X, the pathname separator at the lowest API layer in Mac OS X is slash, but the pathname separator in classic Mac OS was colon, and people may have had files with names with slashes in them, so.... (Yes, there's another such conversion in HFS+, in the opposite direction, so that classic Mac OS and OS X could share HFS+ volumes.)
along with hiding filename extensions...
You can control whether you want that (in Leopard, in the "Advanced" pane of the Finder preferences, select "Show all file extensions"; that might be where it's set in earlier releases). You can also control it on a per-file basis.
I tend to like it, as the icon for a file tells me what it is. (In FreeBSD+KDE, I often didn't need the extension in the file, as file typing was done by looking at file contents.)
Um, are you talking about Interface Builder, which is used for both OSX and iPhone SDKs?
...and used to Build somewhat different Interfaces, given that the screen sizes, input methods, etc. are different on small handhelds than on desktops/laptops.
Of course it is not *exactly* the same in terms of the interface and some hardware specific calls, but the core code for the kernel is *essentially* the same.
If by "the kernel" you mean XNU, that may be the case, but it's no more the case that it's a "twofer" because the kernel is the same than that developing for, say, GNOME+Linux desktops and a (hypothetical) GNOME+Linux-based phone would be a "twofer" because the kernel is the same. The input mechanisms in the UI are very different, the screen size is very different, etc., so, although you could still use open() to open files, read() to read them, etc., you can't assume that you have, for example, a big screen on which to display what you read, a keyboard convenient for lots and lots of typing, etc..
The MVC/KVC models are the same. Sorry, but if you can't design your UI to be intuitive, that not a limitation of Interface Builder but your inability to design to the iPhone/iTouch form factor.
Designing to the iPhone/iPod Touch form factor isn't the same as designing to the desktop/laptop form factor. So, no, it's not a twofer.
I don't know about everyone else here, but from reading TFOP, it looks like he's working for a housing developer trying to build a house that can be controlled from the client's phone (it's not clear whether they are building for a specific client or attempting to sell, but it's irrelevant). As such, the iPhone (or iPod Touch) is the worst possible platform, as the idea is clearly to provide a specific application for one client, and Apple's distribution methods simply do not allow for it.
Ad Hoc distribution?
The Standard and Enterprise Programs allow you to share your application with up to 100 other iPhone or iPod touch users with Ad Hoc distribution. Share your application through email or by posting it to a web site or server.
Presumably you can also just slap the application on your phone and not share it.
I'm just amazed that a criminal organization would file a legal TRADEMARK.
Seriously. Were they going to SUE someone for infringement?
Live to sue, sue to live.