Hacker News new | past | comments | ask | show | jobs | submit login

> but you're locked out of half of what your computer can do.

I'm a pretty big Unix guy, I run Linux desktops and FreeBSD servers, but you're going to need to clarify what you mean by that.

What exactly is the restriction? Assuming you're willing to install some drivers and patch some system dlls, you can generally achieve the same things.

You can very easily disable driver signature enforcement in Windows, as I have and as does anyone who writes drivers for Windows platforms or does low-level reverse engineering work on it. I think the balance of "force signing by default but allow it to be turned off" is a pretty good one, works well for Windows drivers and for Android at least.




> What exactly is the restriction?

All of the below (and the parent post) is my opinion. You can disagree with me, and I'm fine with that.

You're unable to study what your computer actually does. You don't have access to the source of anything that happens in kernel space. You can take university OS courses and tinker with the educational toy operating systems, read about Windows internals but to see what you're actually running is different not only at a philosophical level but also practically.

Yes, you can get into kernel space in Windows by doing a driver DLL, so you can make your computer "do" anything, but what you, as a person, will do is a lot different when dealing with a black box rather than a white box. When doing Windows kernel space driver development, you're reading the documentation (and hope that your computer does what it says), when doing that with an open source OS, you can read the source too (and know that the computer does exactly that).

To me (you don't have to agree), the essence of being a computer is that you don't only use your computer to get work done or use it for entertainment. Computers are the entertainment (and perhaps the work too, like in my case in the semiconductor industry).


> You're unable to study what your computer actually does. You don't have access to the source of anything that happens in kernel space. You can take university OS courses and tinker with the educational toy operating systems, read about Windows internals but to see what you're actually running is different not only at a philosophical level but also practically.

Uhm, or I can fire up windbg and trace through my kernel... not sure what you're getting at (though I do miss the days of softice where I could just hit ctrl+d).

Same goes for pretty much everything else you stated too. We have kernel level debuggers, don't blame me if you can't be bothered to learn a little assembly and trace out the knowledge you need.

Sure, it may not be as easy as C, but it's _very_ possible. It just requires some reverse engineering skill too.

If what you were saying was true, I would absolutely agree with you, but as long as ring0 debuggers exist, it won't be. I find reverse engineering just as exciting if not more so than forward engineering most of the time.


Yeah, sure it's possible but it's quite different to actually getting your hands on the source as well as the version history of the source (why is this code here? git blame and you'll know why) and make changes to it if you want.

As I tried to say, it's more of a philosophical and psychological (and practical) thing than actually being impossible.

Reverse engineering is a valuable skill but it's not too fun when you could just look at the source, with variable names, comments and nice formatting. In some cases it might be a nice "puzzle" to solve but that's not how you want to learn how things work.


> that's not how you want to learn how things work.

Speak for yourself. Some of us appreciate clandestine knowledge all the more.


Beating a dead horse, huh?

I made it clear from the first comment on that it's my opinion and you don't have to agree.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: