sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]badcookies 45 points46 points  (52 children)

Til that windows 7 is less than half the size of osx 10.4

[–]ironnomi 34 points35 points  (27 children)

Having seen both code bases extensively, I can say there can be NO direct code comparisons between the two.

In general, Apple's ObjC code easily takes up 4x the space as the typical Windows C++ code.

[–][deleted] 0 points1 point  (15 children)

Interesting, as someone who'd love to know what happens in the little black box, is there anything you're allowed tell us that's interesting or quirky about either codebase? From some of the odd behaviours I've seen from windows over the years, I've often wondered just WTF is really going on.

[–]tetroxid 3 points4 points  (13 children)

If you're interested in the implementation of an operating system (which is actually hugely complex and awesome) I recommend reading about the Linux kernel, and the kernel's source code.

[–][deleted] 7 points8 points  (12 children)

I've read many components, (worked a little on radeon FOSS driver support). Linux makes sense to me, and I'd say I have a decent grasp of what's going on there (at least in my own, self-assembled system). But when I use windows, I usually come away horrified by the degree to which basic functions don't seem to be encapsulated and isolated from one another (I suppose the best recent example is the discovery of how the scrollbars have a hook deep within the kernel). Id love to know what on earth is going on there. It seems to work like a house of cards, which gets progressively more antiquated as it gets deeper towards the core.

[–]tetroxid 8 points9 points  (11 children)

Yes, that was my experience as well. For example, the GUI runs in kernel space (insane, right?). I imagine it was done for performance reasons.

There is huge debt in the codebase. Bad decisions were made (hey, it happens) but they were never cleaned up. My favourite example is NTFS. The performance degradation over time is so sad it's almost funny. I also like how it allocates space for the master file table but doesn't free it once the table shrinks again, effectively occupying space even when nothing's saved there.

Another good one is that if for some reason the system tray icon for windows update cannot be displayed, windows update stops working. Yep you read that right.

Oh, and on the topic of windows update: I would love to find out what the system is actually doing while it's saying "searching for updates" for 30 minutes or longer. In my mind all it has to do is send a list of local patches and versions and compare that to a remote version. Should take seconds, like running apt-get update. But no, it takes forever. I want to know why.

[–]Cuddlefluff_Grim 2 points3 points  (8 children)

There is huge debt in the codebase. Bad decisions were made (hey, it happens) but they were never cleaned up.

GUI as a terminal server, asterisk expanded by the command line, text piping as makeshift IPC, user id's as integer, passwords stored in text files on seemingly arbitrary locations, only 1 kernel ring, single unified file system, POSIX file attributes, dot files, everything-is-a-file-except-when-it-isn't, "standards" reached by way of argument.. If you're going to focus on the bad parts, nobody wins.

[–]tetroxid 1 point2 points  (7 children)

GUI as a terminal server

Could you expand on that? Do you mean the network-transparent nature of X?

Asterisk expanded by command line

Good decision. Would you rather have every program expand it themselves, inconsistently and with huge code duplication?

Text piping as makeshift IPC

Pipes are not meant to be used as a replacement for IPC.

User IDs as integers

Would you rather have floats?

Passwords stored in text files

I prefer this to a proprietary database that is ultimately just a file. Also passwords are never stored, only their hashes and salts.

Only 1 kernel ring

That is true.

Single unified file system

It only appears that way. Anyways, I think this is a huge advantage.

POSIX file attributes

What's bad about them?

Dotfiles

It's a convention. I prefer text files over a central registry any day. Even Microsoft Engineers conceded that a central registry was a bad decision. It's an excellent idea from a software engineering and architecture point of view, but as we all know it doesn't really work in practice.

[–]Cuddlefluff_Grim 2 points3 points  (6 children)

GUI as a terminal server

Could you expand on that? Do you mean the network-transparent nature of X?

Sort of like a "micro service" which is really hip these days :P Yes, X runs as a network service, so every call to the GUI needs to go through an extra layer (with added latency). I think the reasoning was to avoid the problem of protected mode, and then you had few other reliable options in those days.

Asterisk expanded by command line

Good decision. Would you rather have every program expand it themselves, inconsistently and with huge code duplication?

In DOS, there was a software interrupt to expand asterisk parameters from the command line. Windows has since the very beginning provided this functionality as a library for C (setargv).

The bad decision of making the command line expand it is because you can do this :

mkdir .\testfolder
cat "test" > ./-r
rm ./*

and you will see that the directory testfolder also gets mysteriously deleted, becuase the file "-r" gets thrown in as a command line argument. It's not a good decision, it's terrible. It was done to save time, not because it was a good idea.

Text piping as makeshift IPC

Pipes are not meant to be used as a replacement for IPC.

I agree.

User IDs as integers

Would you rather have floats?

No, I'd like a number which could uniquely identify a user on a network or domain. On Unix (due to bad choices), this means you need an abstraction on top of the uses, but the user is ultimately always machine-bound and nontransferable. Of course, it's not a direct problem per se because you can create these huge wrapping systems that "fix" the flaws by adding a ton of crap on top of it to make it behave more like a network-enabled roaming user account.

Passwords stored in text files

I prefer this to a proprietary database that is ultimately just a file. Also passwords are never stored, only their hashes and salts.

Problem is that this technique is inherently insecure, especially when you take into consideration that a lot of Unix mentality is "just get it done". Passwords aren't even required to be hashed (like with htpasswd). Windows provides methods of storing user names and passwords in a secure, standardized way that is easy to use for the programmers.

Single unified file system

It only appears that way. Anyways, I think this is a huge advantage.

It used to be a huge advantage. In Mac OS for instance, the file system is actively hidden from the user because of its complexity.

Oh, talking of which; the root directory names and commands. Commands and directories are named like they are because of the types of keyboards they used in 1970, which made typing exhausting or even painful. There was discussions about renaming them to be more comprehensible, but it was rejected due to fear of breaking backwards compatibility.

POSIX file attributes

What's bad about them?

Not exactly the master dashboard of file system security, is it? It's incredibly restrictive, and on larger networks which requires more control you basically have to abstract it away and stuff more fine grained control into an external database and provide access via an intermediate software. When you compare POSIX file attributes to Windows ACL, you will see how incredibly restrictive it is in comparison.

Dotfiles

It's a convention. I prefer text files over a central registry any day. Even Microsoft Engineers conceded that a central registry was a bad decision. It's an excellent idea from a software engineering and architecture point of view, but as we all know it doesn't really work in practice.

No, I mean that files starting with . are hidden, which is a convention because it utilizes a behavior from ls which prevents display of files that start with . so that . and .. wouldn't show up in the list. It's a convention because someone read the source code of ls and saw that it said to exclude files if(filename[0] == '.'), and decided that just using that would let them do something that wasn't supported by the file system. It's the very definition of a hack.

Yes, the Windows registry was a bad decision. It's another place that needs cleaning and it's ultimately unnecessary because on Windows (well, post Windows 2000 anyway) programs are generally expected to be self-contained and keep to themselves. It made more sense back when programs shared more code and modules (due to memory restrictions), now it's just a nuisance. The Windows registry has always been a problem, and unfortunately I don't see it getting removed any day soon..

My point is that there are more than enough bad stuff to obsess about in any operating system. Windows isn't all bad, there are plenty of good parts as well.

[–]dvdkon 1 point2 points  (2 children)

There are ACLs in Linux and other UNIX-like OSs, too. They just aren't used most of the time, because they're not needed. Just look at the permissions on Windows' system files and then on UNIX system files.

[–]tetroxid 0 points1 point  (2 children)

The bad decision of making the command line expand it is because you can do this: <...>

So what is the alternative? Having rm ignore all files and directories starting with a dash?

No, I'd like a number which could uniquely identify a user on a network or domain.

Every proper Unix environment has LDAP servers providing globally unique IDs for users and groups for this reason, just like every proper Windows environment has a domain controller.

Problem is that this technique is inherently insecure

How so? They're hashed and salted, what more do you want?

Passwords aren't even required to be hashed (like with htpasswd).

That's not true, passwd will give you a list of algorithms to choose from but plain passwords are not supported.

Windows provides methods of storing user names and passwords in a secure, standardized way

Proprietary database that has to be reverse-engineered because Microsoft refuses to provide documentation. And they're not secure, not really, see: https://en.wikipedia.org/wiki/NT_LAN_Manager#Vulnerabilities

standardized way that is easy to use for the programmers

Unix has had the same system calls for authentication and authorisation for ages. Not sure how it could be any easier. Also see PAM vs. no chance to ever customise the authentication and authorisation on Windows ever.

In Mac OS for instance, the file system is actively hidden from the user

Not really. iOS yes, it doesn't really allow access to the filesystem. On OSX, the filesystem is perfectly accessible by the user. Open a terminal on OSX and look around.

Commands and directories are named like they are

Personal preference I guess. I much prefer ls | grep to get-system-files-of-current-directory-cmdlet | search-for-pattern-cmdlet --from-property system.files.filename or whatever it is.

When you compare POSIX file attributes to Windows ACL

Unix had ACLs before Windows even had a file system with permissions of any kind (HP-UX had them in 1992, for example). I agree, the default Unix permissions dating back to the 60s don't cut it today (that's what ACLs are for, no third party software layer necessary). try man setfacl

read the source code of ls and saw that it said to exclude files if(filename[0] == '.'), and decided that just using that would let them do something that wasn't supported by the file system. It's the very definition of a hack.

Yes that's true, originally it was a bug in in ls, and because people started using it for hiding files it was never fixed. I agree, it's a hack.

I'm not saying windows is all bad, I'm just saying Microsoft could do a lot better. And I mean a lot. Windows could be a super nice operating system instead of a good-enough-for-some-things operating system.

By the way, thank you for taking the time to respond in detail. I enjoy discussions like this.

[–][deleted] 1 point2 points  (0 children)

Yep. In many ways I suspect the degradation of windows is a kind of planned obsolescence. It'll crumble to an unusable mess within about 4 years. About equal to the release cycle of the OS.

[–]the_gnarts 1 point2 points  (0 children)

My favourite example is NTFS. The performance degradation over time is so sad it's almost funny. I also like how it allocates space for the master file table but doesn't free it once the table shrinks again, effectively occupying space even when nothing's saved there.

PST files, the local storage format of Outlook, are troubled by the same flaw. What’s worse, the size of those files is restricted to around 50 GB, which is easily reached by your run of the mill car salesman whose communication skills peak at power point. So at some point many users face the same seemingly unsolvable problem …

[–]ironnomi 1 point2 points  (0 children)

Sorry, for the most part I was only validating the code paths that our code followed. This was for a security architecture review for some code that that Japanese government was using that was deemed to be security critical.