It's not "their own" in the sense of not being part of the Unicode standard; both forms C and D are part of the standard. Mac OS X happens to be the only system I know of that uses form D, however.
Note that when the man page in question says that Darwin prevents the creation of files with names that aren't valid form D UTF-8 strings "at filesystem layer", "filesystem layer" refers to HFS+, not to the VFS layer; you can create files with names that aren't valid form D UTF-8 strings on UFS, for example. Also, attempts to create files with form C UTF-8 names on HFS+ will, as far as I know, be treated as attempts to create files with the equivalent form D UTF-8 names. The SMB client assumes UTF-8 file names and converts them to form C UTF-16 names over the wire, as that's what Windows prefers; VFAT and NTFS might do the same. The NFS client doesn't care - it just passes the bytes over the wire; what gets done with those bytes is up to the server.
Mac OS X 10.3 and later support a case sensitive file system, but it is not used by default.
Actually, even older versions have a case-sensitive file system. It's called "UFS".:-)
10.3 and later support HFSX, which is a version of HFS+ extended to support either case-insensitive or case-sensitive file system operations; 10.3's support of HFSX might not have been as complete as 10.4's. As you note, HFSX isn't used by default, so 10.4 is, by default, case-insensitive.
linux et,al. == case sensitive
windows == case insensitive
OSX == case preserving
Err... no.
Linux, et al with their default file systems == case-sensitive
Windows, OS X with HFS+ == case-insensitive
All of the above == case-preserving (except maybe Windows with VFAT).
"Case-preserving" just says whether, if you supply the name "CamelCase.txt" in a call to create a file, the file ends up called "CamelCase.txt" or ends up as "camelcase.txt" or "CAMELCASE.TXT" or something annoying such as that. A case-sensitive system will almost certainly be case-preserving (anything else would be silly); a case-insensitive system can be case-preserving or not, but case-preserving is nicer.
...or in a X11-based app (i.e., in anything that uses standard UN*X calls to operate on files and doesn't use Apple file dialogs)...
you can create file names with colon, but such character is mapped to a forward slash when seen in Finder.
...or in standard Apple dialogs.
Historically, Mac OSes use colon to separate folder names in a path.
...which is why the Carbon layer does colon slash mapping for file/path names passed to UN*X calls or file names and file/path names returned by UN*X calls.
There is a subtle restriction in HFS+. All files in HFS+ have their names in normalized unicode
Normalization Form D, to be precise - unlike Normalization Form C, which Windows and most other UN*Xes use. This can cause some additional problems.
turned out they were remote copying from one Unix that had 14 (or more, can't remember) char limit
Probably 14 - the old UNIX file systems had 16-byte directory entries, with 2 bytes of inode number and 14 bytes of file name.
on file names to an old SunOS system that allowed only 11
Where did you find a SunOS system like that? SunOS, all the way back to "Sun UNIX 4.2BSD Release 1.0" or whatever it announced itself as, always used the BSD Fast File System, with 255 bytes as the length limit, and even the old Unisoft ports probably had a traditional UNIX file system with a 14-byte limit.
but my main point was that Apple might have worked into a special case for HFS+ into the very lowest layer
The very lowest layer in the kernel is in HFS+, and the special case is that it stores ":" in file names on disk as "/" and returns "/" in on-disk file names as ":". It expects to be handed, from the VFS layer, file names that do not contain "/", and it handles file names that contain ":", treating the ":" as a regular file name character; it just translates ":" to "/" in the on-disk data structures so that pre-OS X versions of Mac OS won't get upset if they try to read the volume.
That's all invisible to stuff above it, though. At the UN*X layer ("BSD layer", "POSIX layer") all pathnames have "/" as separators and ":" is treated as an ordinary file name character.
and have a system for supporting file systems that from the looks of it is non-standard (check/System/Library/Filesystems/)
That's not really a system for supporting file systems, it's just a place where some of the file-system-specific OS code and data files are put. Other code is put in/System/Library/Extensions (the kernel loadable modules for those file systems implemented as loadable modules) or in/sbin (newfs/fsck/mount programs for particular file systems).
There's no such thing, relatively, and in this context, as a "pure Cocoa app", because as far as I know Cocoa builds on Carbon in order to simplify and not repeat very low-level primitives.
I think Cocoa might compensate for Carbon's mapping between colon and slash by doing its own mapping.
I have no idea if Apple's implementation of the POSIX layer does this automatically, but it'd make sense.
In the kernel and libSystem, at or above the VFS layer, the POSIX layer knows nothing of Carbon's "let's pretend this is classic Mac OS" transformations. The pathname separator is slash, and colon is just another file name character just like any other character. Below the VFS layer, HFS+ does its own mapping, so that the file system can be understood by pre-OS X versions of Mac OS but the code above it would see it as a regular UN*X file system with colons allowed in file names, and the AFP client and server might do that as well for the same reason. The other file systems that came from BSD file systems (UFS, NFS, smbfs, FAT/VFAT, NTFS, and the ISO 9660 file system), and UDF, don't do any such mapping.
So any UN*X-layer calls made directly by Cocoa would have slash as a pathname separator and colon as just another character in file names. (And, yes, this means that if Cocoa turns colons into slashes and slashes into colons and hands the resulting pathname to the Carbon File Manager, and the resulting access is to a file on an HFS+ file system, "Start: section 1" will get mapped to "Start/ section 1" by Cocoa, "Start/ section 1" will be mapped to "Start: section 1" by Carbon, and "Start: section 1" will be mapped by HFS+ to "Start/ section 1" for storage on disk. The joys of backwards compatibility....)
A strong objection I have to OSX's treatment of files is its practice of creating one invisible file for every visible file (differing in name only by a preceding dot).
No, a preceding dot followed by an underscore. It shouldn't be doing that for every file, only for files that
are stored on a file system where the OS X code doesn't natively support the resource fork/Finder attributes and
have a resource fork or Finder attributes added to them.
That still might be most of the files you see in some cases.
At the Carbon layer, path names with colon separators are mapped to UN*X path names with slash separators by mapping colons to slashes and vice versa, and file names coming up from the UN*X layer (readdir(), getdirentriesattr(), etc.) have colons mapped to slashes by the Carbon layer. A pure Cocoa app might be able to see the real UN*Xness underneath, given that Cocoa is the descendant of the old NeXTStEP stuff. The Finder's a Carbon app, so it mostly shows you the Carbon view of the world (but in some places, you see UN*X paths, e.g. in the "Where:" part of the "General:" information in the Info dialog for the file).
(Also, on disk, the HFS+ code maps colons to slashes on incoming file names and maps slashes to colons on outgoing file names, so files are stored on-disk in the old Mac OS style, so that older versions of Mac OS can still read the volume but it looks like a UN*X file system to code at the VFS layer and above in OS X.)
I can't verify that the software is actually better anymore. Could be the Intels make them crash as often as a regular PC
If that were true, then Linux, FreeBSD, NetBSD, OpenBSD, and DragonFlyBSD would have to, when running on a regular PC, crash as much as Windows, too. If they don't, then perhaps PowerPC isn't as magical as you appear to think it is.
Re:Resource forks sound like NTFS streams
on
WinFS Gets the Axe
·
· Score: 1
Microsoft implemented it in NTFS to be compatible with the Mac FS.
I doubt that was the only reason they did it (if it was a reason at all), given that Mac OS (pre-X and X) supports only two data streams for a file (data fork and resource fork), while NTFS supports an arbitrary (well, modulo stream name length limitations and the like) number of data streams.
I don't think any application made a good usage of it...
Whether it's a good use is perhaps a matter of taste, but I've seen SMB stream opens and reads go over the wire from at least some applications, so some Microsoft code uses them if present. ("If present" might be part of the problem; any code that requires them also requires NTFS, which rules out Windows 95/98/Me and, I think, XP Home, at least in its default configuration.)
so we can replace Spotlight with something that indexes FILENAMES!
I presume you mean "indexes only file names", because Spotlight most definitely does index file names. The standard search box does a search for the name anywhere, but if you hit Cmd+F in a Finder window, you can search for files by name, and that search uses the Spotlight database (get rid off the "Last Opened" item, and change the "Kind" item to "Name"; I presume those defaults are useful to somebody, but they're never what I want).
Re:Bzzzzt ...Wrong. Thank you for playing
on
WinFS Gets the Axe
·
· Score: 3, Insightful
Wrong. It's the hooks into the filesystem that allow notification for spotlight to update.
To be more precise, it's the hooks into the VFS layer that allow notification for Spotlight to update. Take a look at bsd/vfs/vfs_vnops.c in xnu (you might need to sign up for a free ADC Online membership in order for that link to work). In particular, take a look at vn_close - in particular the..._fsevent calls. (NOTE: this is not a published interface, and is subject to change without notice. Don't start using it in your apps unless you're prepared for an app to stop working in a future release; it might continue to work in future releases, or it might not.)
My home directory at work is on an NFS server, and everything under it it's indexed by Spotlight. It happens to be on an HFS+ partition on the server, but Spotlight on my machine has no clue that it happens to be on HFS+, and the indexing of my stuff there is done by Spotlight running on my machine, not on the server, so no hooks into HFS+ were used to do the change notification (because, among other things, no such hooks exist; the hooks are in the VFS layer, above the individual file systems).
When you look at it, you wonder why the US designers are so retarted to design ugly stuff like the KSR-33.
To be fair, the IBM 2741 isn't quite so ugly, and the IBM 1050 was also a bit less clunky-looking (i.e., they, like the Olivetti, look more as if they actually belong in the Swinging '60's than did the Models 33 and 35 Teletypes). Even Teletype came out with the Model 37 eventually....
AFAIK, there is precious little code from a BSD kernel in the Apple kernel.
YDK. Take a look at xnu/bsd/ufs, xnu/bsd/vfs, xnu/bsd/nfs, xnu/bsd/net, xnu/bsd/netinet, xnu/bsd/netinet6, and many of the files in xnu/bsd/kern. It's not just "straight BSD code", but, then again, if you compare, for example, the FreeBSD and NetBSD versions of the corresponding directories, you'll find differences, so it's not as if "straight BSD code" would refer to anything other than the 4.4-Lite versions of those directories, and *BSD has diverged from 4.4-Lite there just as Darwin has.
Linux uses these for e.g. telling the difference between an executable script and a binary file
...as did a lot of other UN*Xes before Linux even existed. The original a.out file format started with a 16-bit octal 0407, which, as I remember, was a PDP-11 jump around the rest of the executable image header, presumably because the entire executable file, header and all, was read into the address space; one of the exec-family calls would fail if it didn't see the 0407. Later, other magic numbers were added for executables that had a shared code segment and a non-shared data segment, and for executables where the code shared segment and shared data segment were in separate address spaces ("split I and D space"). That tradition was continued with a.out on other machines.
Eventually, some (ultimately most, if not all) UN*Xes also recognized "#!" as a magic number, meaning "read the rest of the line, and run the program specified there, with the optional argument specified there if present, and with the name of the script and the arguments to the exec call. Executable image formats other than a.out were given their own magic numbers, so the exec-family calls could know what format the file was.
You mean the difference between "bred" and "fucked"? Rather a major semantic difference, especially in this context.
"Centralize breeding" was referring to the hatcheries in Brave New World; in the world of BNW, people did plenty of fucking, but none of it was supposed to produce children (fucking to make babies was what savages did). Children were produced artificially in hatcheries (I forget where the book said the eggs and sperm came from; the Sparknotes page for BNW says the eggs came from surgically-removed ovaries - the former owners of the ovaries were probably mostly happy to see them go, as it meant they didn't have to worry about getting pregnant), as an industrial process, making the right number of children in each category from Alphas to Epsilons.
Its kernel is based on BSD which wasn't designed to have locks, so locking is much more coarse than it needs to be.
Few, if any, current UN*Xes were "designed to have locks", but many of them (Solaris, Linux, FreeBSD, OS X) have made their locks finer-grained anyway; it's not as if you're stuck with all the consequences of the "design" forever.
The Mach base (which as far as I can tell is completely unnecessary) adds extra indirection to system calls.
What are some examples of this extra indirection? (Note that system calls are not redirected to userland servers.)
Macs are intended to be a single-user interactive system, and most apps spend most of their time waiting for the user, so perf just isn't the high priority it has to be on Windows.
Windows personal computers (as opposed to servers) aren't intended to be single-user interactive systems?
Pre-10.4 releases had coarser locking (the "funnels") than did 10.4[.x]. It'd be interesting to see what happens with your tests on 10.4[.x], where the locking is more fine-grained.
(I also hope 10.3.x wasn't actually copying any data on those writes. If so, that's a cheap and easy "microbenchmark" hack; any UN*X whose/dev/null write routine does anything more than return a success indication is doing more work than it needs to. Heck, we knew about that in the SunOS 4.0 days - "cp" mmapped the input file, and the write to "/dev/null" from the mapped region didn't actually do any work, so it went really fast.)
Werent we told recently that we no longer have the right to make modifications and compile the apple kernel from source?
No.
Maybe it would be useful to look at it for learning purposes, but now-a-days I believe you can get into quite a bit of trouble if you look at source code thats not your own then go off to make your own project under a different licence.
"Now-a-days"? Try releasing a *BSD system under the GPL, or the Linux kernel+glibc under a BSD license, and see how much trouble you get into.
Whether looking at project X and using its ideas when writing a new project gets you into trouble is another matter. I'm not sure whether the GPL or the modified BSD license or the APSL limits what you can do if you read code covered by that license or not.
"Re-engineered" as in "has a significantly different microarchitecture", although one might consider it a remote descendant of the original Pentium Pro microarchitecture, and a successor to the Pentium M microarchitecture.
The confusing part is that "Core" is used both as part of a brand and as part of the name of a microarchitecture, and not all chips with the "Core" brand use the Intel Core Microarchitecture (in fact, none of the currently-available chips with the "Core" brand use the Intel Core Microarchitecture - they use the Pentium M microarchitecture with SSE3 and some other stuff added).
Slashdot Mirror
...with a DSL line for its Internet connection.
It's not "their own" in the sense of not being part of the Unicode standard; both forms C and D are part of the standard. Mac OS X happens to be the only system I know of that uses form D, however.
Note that when the man page in question says that Darwin prevents the creation of files with names that aren't valid form D UTF-8 strings "at filesystem layer", "filesystem layer" refers to HFS+, not to the VFS layer; you can create files with names that aren't valid form D UTF-8 strings on UFS, for example. Also, attempts to create files with form C UTF-8 names on HFS+ will, as far as I know, be treated as attempts to create files with the equivalent form D UTF-8 names. The SMB client assumes UTF-8 file names and converts them to form C UTF-16 names over the wire, as that's what Windows prefers; VFAT and NTFS might do the same. The NFS client doesn't care - it just passes the bytes over the wire; what gets done with those bytes is up to the server.
Actually, even older versions have a case-sensitive file system. It's called "UFS". :-)
10.3 and later support HFSX, which is a version of HFS+ extended to support either case-insensitive or case-sensitive file system operations; 10.3's support of HFSX might not have been as complete as 10.4's. As you note, HFSX isn't used by default, so 10.4 is, by default, case-insensitive.
Err... no.
Linux, et al with their default file systems == case-sensitive
Windows, OS X with HFS+ == case-insensitive
All of the above == case-preserving (except maybe Windows with VFAT).
"Case-preserving" just says whether, if you supply the name "CamelCase.txt" in a call to create a file, the file ends up called "CamelCase.txt" or ends up as "camelcase.txt" or "CAMELCASE.TXT" or something annoying such as that. A case-sensitive system will almost certainly be case-preserving (anything else would be silly); a case-insensitive system can be case-preserving or not, but case-preserving is nicer.
...or in a X11-based app (i.e., in anything that uses standard UN*X calls to operate on files and doesn't use Apple file dialogs)...
...or in standard Apple dialogs.
...which is why the Carbon layer does colon slash mapping for file/path names passed to UN*X calls or file names and file/path names returned by UN*X calls.
Normalization Form D, to be precise - unlike Normalization Form C, which Windows and most other UN*Xes use. This can cause some additional problems.
Probably 14 - the old UNIX file systems had 16-byte directory entries, with 2 bytes of inode number and 14 bytes of file name.
Where did you find a SunOS system like that? SunOS, all the way back to "Sun UNIX 4.2BSD Release 1.0" or whatever it announced itself as, always used the BSD Fast File System, with 255 bytes as the length limit, and even the old Unisoft ports probably had a traditional UNIX file system with a 14-byte limit.
The very lowest layer in the kernel is in HFS+, and the special case is that it stores ":" in file names on disk as "/" and returns "/" in on-disk file names as ":". It expects to be handed, from the VFS layer, file names that do not contain "/", and it handles file names that contain ":", treating the ":" as a regular file name character; it just translates ":" to "/" in the on-disk data structures so that pre-OS X versions of Mac OS won't get upset if they try to read the volume.
That's all invisible to stuff above it, though. At the UN*X layer ("BSD layer", "POSIX layer") all pathnames have "/" as separators and ":" is treated as an ordinary file name character.
That's not really a system for supporting file systems, it's just a place where some of the file-system-specific OS code and data files are put. Other code is put in /System/Library/Extensions (the kernel loadable modules for those file systems implemented as loadable modules) or in /sbin (newfs/fsck/mount programs for particular file systems).
I think Cocoa might compensate for Carbon's mapping between colon and slash by doing its own mapping.
In the kernel and libSystem, at or above the VFS layer, the POSIX layer knows nothing of Carbon's "let's pretend this is classic Mac OS" transformations. The pathname separator is slash, and colon is just another file name character just like any other character. Below the VFS layer, HFS+ does its own mapping, so that the file system can be understood by pre-OS X versions of Mac OS but the code above it would see it as a regular UN*X file system with colons allowed in file names, and the AFP client and server might do that as well for the same reason. The other file systems that came from BSD file systems (UFS, NFS, smbfs, FAT/VFAT, NTFS, and the ISO 9660 file system), and UDF, don't do any such mapping.
So any UN*X-layer calls made directly by Cocoa would have slash as a pathname separator and colon as just another character in file names. (And, yes, this means that if Cocoa turns colons into slashes and slashes into colons and hands the resulting pathname to the Carbon File Manager, and the resulting access is to a file on an HFS+ file system, "Start: section 1" will get mapped to "Start/ section 1" by Cocoa, "Start/ section 1" will be mapped to "Start: section 1" by Carbon, and "Start: section 1" will be mapped by HFS+ to "Start/ section 1" for storage on disk. The joys of backwards compatibility....)
No, a preceding dot followed by an underscore. It shouldn't be doing that for every file, only for files that
That still might be most of the files you see in some cases.
Exactly. It's a UN*X.
At the Carbon layer, path names with colon separators are mapped to UN*X path names with slash separators by mapping colons to slashes and vice versa, and file names coming up from the UN*X layer (readdir(), getdirentriesattr(), etc.) have colons mapped to slashes by the Carbon layer. A pure Cocoa app might be able to see the real UN*Xness underneath, given that Cocoa is the descendant of the old NeXTStEP stuff. The Finder's a Carbon app, so it mostly shows you the Carbon view of the world (but in some places, you see UN*X paths, e.g. in the "Where:" part of the "General:" information in the Info dialog for the file).
(Also, on disk, the HFS+ code maps colons to slashes on incoming file names and maps slashes to colons on outgoing file names, so files are stored on-disk in the old Mac OS style, so that older versions of Mac OS can still read the volume but it looks like a UN*X file system to code at the VFS layer and above in OS X.)
I believe you are correct.
If that were true, then Linux, FreeBSD, NetBSD, OpenBSD, and DragonFlyBSD would have to, when running on a regular PC, crash as much as Windows, too. If they don't, then perhaps PowerPC isn't as magical as you appear to think it is.
Why? What advantage did it offer over doing the same functions in low-level OS software, for example?
Unreleased product?
I doubt that was the only reason they did it (if it was a reason at all), given that Mac OS (pre-X and X) supports only two data streams for a file (data fork and resource fork), while NTFS supports an arbitrary (well, modulo stream name length limitations and the like) number of data streams.
Whether it's a good use is perhaps a matter of taste, but I've seen SMB stream opens and reads go over the wire from at least some applications, so some Microsoft code uses them if present. ("If present" might be part of the problem; any code that requires them also requires NTFS, which rules out Windows 95/98/Me and, I think, XP Home, at least in its default configuration.)
I presume you mean "indexes only file names", because Spotlight most definitely does index file names. The standard search box does a search for the name anywhere, but if you hit Cmd+F in a Finder window, you can search for files by name, and that search uses the Spotlight database (get rid off the "Last Opened" item, and change the "Kind" item to "Name"; I presume those defaults are useful to somebody, but they're never what I want).
To be more precise, it's the hooks into the VFS layer that allow notification for Spotlight to update. Take a look at bsd/vfs/vfs_vnops.c in xnu (you might need to sign up for a free ADC Online membership in order for that link to work). In particular, take a look at vn_close - in particular the ..._fsevent calls. (NOTE: this is not a published interface, and is subject to change without notice. Don't start using it in your apps unless you're prepared for an app to stop working in a future release; it might continue to work in future releases, or it might not.)
My home directory at work is on an NFS server, and everything under it it's indexed by Spotlight. It happens to be on an HFS+ partition on the server, but Spotlight on my machine has no clue that it happens to be on HFS+, and the indexing of my stuff there is done by Spotlight running on my machine, not on the server, so no hooks into HFS+ were used to do the change notification (because, among other things, no such hooks exist; the hooks are in the VFS layer, above the individual file systems).
To be fair, the IBM 2741 isn't quite so ugly, and the IBM 1050 was also a bit less clunky-looking (i.e., they, like the Olivetti, look more as if they actually belong in the Swinging '60's than did the Models 33 and 35 Teletypes). Even Teletype came out with the Model 37 eventually....
"Backwards compatibility"? A lot of anti-productivity software is designed for Windows; it's not just a bunch of old DOS software.
Not that UN*X+X11 doesn't compete there.
At least Apple doesn't bundle much in the way of anti-productivity software with OS X - no Solitaire, for example.
YDK. Take a look at xnu/bsd/ufs, xnu/bsd/vfs, xnu/bsd/nfs, xnu/bsd/net, xnu/bsd/netinet, xnu/bsd/netinet6, and many of the files in xnu/bsd/kern. It's not just "straight BSD code", but, then again, if you compare, for example, the FreeBSD and NetBSD versions of the corresponding directories, you'll find differences, so it's not as if "straight BSD code" would refer to anything other than the 4.4-Lite versions of those directories, and *BSD has diverged from 4.4-Lite there just as Darwin has.
...as did a lot of other UN*Xes before Linux even existed. The original a.out file format started with a 16-bit octal 0407, which, as I remember, was a PDP-11 jump around the rest of the executable image header, presumably because the entire executable file, header and all, was read into the address space; one of the exec-family calls would fail if it didn't see the 0407. Later, other magic numbers were added for executables that had a shared code segment and a non-shared data segment, and for executables where the code shared segment and shared data segment were in separate address spaces ("split I and D space"). That tradition was continued with a.out on other machines.
Eventually, some (ultimately most, if not all) UN*Xes also recognized "#!" as a magic number, meaning "read the rest of the line, and run the program specified there, with the optional argument specified there if present, and with the name of the script and the arguments to the exec call. Executable image formats other than a.out were given their own magic numbers, so the exec-family calls could know what format the file was.
You mean the difference between "bred" and "fucked"? Rather a major semantic difference, especially in this context.
"Centralize breeding" was referring to the hatcheries in Brave New World; in the world of BNW, people did plenty of fucking, but none of it was supposed to produce children (fucking to make babies was what savages did). Children were produced artificially in hatcheries (I forget where the book said the eggs and sperm came from; the Sparknotes page for BNW says the eggs came from surgically-removed ovaries - the former owners of the ovaries were probably mostly happy to see them go, as it meant they didn't have to worry about getting pregnant), as an industrial process, making the right number of children in each category from Alphas to Epsilons.
Few, if any, current UN*Xes were "designed to have locks", but many of them (Solaris, Linux, FreeBSD, OS X) have made their locks finer-grained anyway; it's not as if you're stuck with all the consequences of the "design" forever.
What are some examples of this extra indirection? (Note that system calls are not redirected to userland servers.)
Windows personal computers (as opposed to servers) aren't intended to be single-user interactive systems?
Pre-10.4 releases had coarser locking (the "funnels") than did 10.4[.x]. It'd be interesting to see what happens with your tests on 10.4[.x], where the locking is more fine-grained.
(I also hope 10.3.x wasn't actually copying any data on those writes. If so, that's a cheap and easy "microbenchmark" hack; any UN*X whose /dev/null write routine does anything more than return a success indication is doing more work than it needs to. Heck, we knew about that in the SunOS 4.0 days - "cp" mmapped the input file, and the write to "/dev/null" from the mapped region didn't actually do any work, so it went really fast.)
No.
"Now-a-days"? Try releasing a *BSD system under the GPL, or the Linux kernel+glibc under a BSD license, and see how much trouble you get into.
Whether looking at project X and using its ideas when writing a new project gets you into trouble is another matter. I'm not sure whether the GPL or the modified BSD license or the APSL limits what you can do if you read code covered by that license or not.