OSDev.org

Keep in mind you're using 11.04 and I'm using 12.04

I'm using 12.04 here at work and just installed Skype from .deb

JamesM wrote:

Keep in mind you're using 11.04 and I'm using 12.04

I'm using 12.04 here at work and just installed Skype from .deb

They must've fixed it then. Before when I tried downloading it from the USC it was broken.

It wasn't really a problem though, I mean, I could just use alien to install .rpm's.

I'm using Debian Squeeze (version 6.*) and I don't hate anything on it.
(Comes with ALL the OSDev tools.)

But I hate everything on MY os

I am currently using the ancient Windows NT 4.0 on my main computer.

What I hate about NT 4.0:
[*] BSOD-alike screen all the time it boot
[*] No official USB support.
[*] DirectX 3.0 is unusable with new software, OpenGL support is somewhat unreliable = almost no hardware video acceleration, making watching 480p h264 on Pentium III 800MHz impossible.
[*] No new modern web browsers, the most recent one can run on NT 4.0 is Opera 10.63
[*] In order to install programs like MPlayer,... I have to do it "linux way": Download source and using MinGW to compile.

If Microsoft add USB support, DirectX, Win32 subsytem update to Windows NT 4.0, I will never need to use new Windows.

Windows NT is a solid OS, it is modular, extensible and portable by design. But Microsoft does not let user buy Windows in seperated components. I need USB support but I cannot buy USB support module from Microsoft, I must buy Windows 2000. Using Windows XP but need new DirectX? Buy Windows 7. Microsoft is only care about profit.

Congdm wrote:I am currently using the ancient Windows NT 4.0 on my main computer.

Why? I kinda get why because in my opinion NT 4.0 was the best Windows ever but why do you use it on your main machine if it has so many prolems?

JuEeHa wrote:Why? I kinda get why because in my opinion NT 4.0 was the best Windows ever but why do you use it on your main machine if it has so many prolems?

It has problems but save me from many problems of another Windows version. When using XP, I need to reinstall it countless times, but with NT 4.0, I rarely need to reinstall.
A new version of Linux or BSD would be better but I didn't like UNIX-style, so I stick with NT 4.0

Shamefully I must admit having a /dev/sda2 containing Windows 7. I really don't like that system from a technical point of view. It's a bit interesting how my knowledge of it is almost gone after having used Linux full time for 3-4 years.

Normally I run Linux Mint. I rather like how it "just works" which is very important to me - not because I can't fix it if it broke - but because that's the ideal computer experience. There are, of course, things I don't like about Linux. For instance, I don't like how many operations are needlessly root-only, for instance chroots, mounting, and that there isn't Plan 9-style namespaces. Setuid executables should also just go away, they are simply bad from a security point of view. They are also incompatible with the Unix philosophy that processes inherit their properties through fork(), but setuid programs expect a safe and secure state and thus try to reject malicious environmental variable and such. It is just ugly. I would also like if the filesystem hierachy was better at allowing coexistence of files from conflicting architectures, though things are improving with stuff such as /usr/lib/x86_64-linux-gnu/. The PATH variable also seems like a hack, I'd prefer /bin to be directory union. And so on.

I have two PCs, one running only Windows Vista, the other Gentoo Linux. I like both for different reasons, but that isn't what this thread is about!

Things I hate on my Windoze box:
10. UAC - can be disabled, but so annoying it deserves mention
9. random crashes - usually a sh***y 3rd party driver or program, but Microsoft deserves some blame for making it so easy
8. outdated command line - sure, they added a few commands since DOS, but I still haven't seen Conway's Game of Life implemented in a batch file.
7. .NET - I always hated .NET irrationally, and I still do, even if it would be easier than coding with Win32 and COM interfaces.
6. it's popular - This means more viruses, exploits, worms, and other ne'er do wells are aimed at it.
5. it's made by Microsoft - They're less evil than they used to be but they still try to control hardware manufacturers with crap like Restricted Boot.
4. Windows Defender - Along with that Security Center almost as annoying as UAC but once again, can be disabled once you've got a good antivirus installed.
3. Development Tools too geared towards IDEs - Microsoft's C compiler and assembler are great for windows programming but you have to jump through several hoops to use them from the command line, and I had to install the whole Visual Studio Express Edition to get them all.
2. PRINT "MICRO$OFT RULES"
1. GOTO 10

Things I hate about lunix (and UNIX in general):
10. The UNIX Hater's Handbook pretty much nails everything, although a lot of it is outdated.
2. It's easy to screw up big time, and hard to undo said screw ups.
1. Lack of documentation. Not as bad as it used to be, but a lot of the existing documentation is too terse.

Congdm wrote:[*] DirectX 3.0 is unusable with new software

There is, from what I have heard, an unofficial upgrade for NT4 to DirectX 5. That's not much of an improvement, but it's something that might help a bit. Google a bit, you might find it.

The one thing I hate more than anything else in the world is that the GUI APIs are not threadsafe. This one thing turns GUI programming into 10 times more of a nightmare than it needs to be. The next worst thing is that the GUI APIs keep evolving and getting deprecated -- there is a great deal to be said for the concept of getting it right the second or third time! The next worst thing is the deplorable paging algorithms on all my "commercial" OSes -- they slow my systems to a crawl when they activate. And then I will add a comment about the horrible API documentation on every API that I know of.

bewing wrote:The one thing I hate more than anything else in the world is that the GUI APIs are not threadsafe.

What? A properly written GUI application is thread-safe in modern OS (either direct all event into "GUI event thread" or grand central dispatch)
And for calling API it's the caller's responsibility for not accessing same resources on multiple threads - just as you won't access same memory in multiple threads.

And for calling API it's the caller's responsibility for not accessing same resources on multiple threads - just as you won't access same memory in multiple threads.

Lol -- what else do you do with multiple threads except access the same memory?
And I completely disagree. The whole point of threading a GUI app is to be able to update widgets in the background. Therefore, it's essential to be able to modify any widget asynchronously from any thread of a process, at any time. Thread restrictions beyond that are unreasonable.

I meant, access the same resource without proper synchronization (by use of mutex, etc).


On older OS(and android!), you may be correct - the OS internal is not designed for re-entry, and some activity cannot be invoked other than main thread (It's true even for older DirectX where you must call function on same thread for creation of object).

However, on modern OS it's possible to invoke function from any thread, provided that the caller do proper synchronization - and I call that thread-safe.

bewing wrote:The whole point of threading a GUI app is to be able to update widgets in the background.

Wrong. The whole point of threading a GUI app is to be able to update widgets from the background. Or actually, do stuff so that the GUI remains responsive.

Try solving the case where one thread modifies a widget and another modifies a child of it, and at some point they need to access each other. Fix the deadlock.

I disagree. It's easy to fix deadlocks within my own code -- there are dozens of solutions to the hungry philosophers problem.

The point is that, in general, there are no locking issues. I need to build a listview in the background. When it is complete, it will be displayed in the foreground. No problem. Except that in most APIs it can't be done. One thread generates a bunch of text that needs to go into a textbox. Oh darn! It's the wrong thread! Suddenly what should be one call to SetWidgetText() turns into a maze of trying to pass a message and a pointer and a length into the "correct" thread, so it can do the call FOR the other thread -- hopefully before the data gets stale (so you need to protect against that) ....

The problem lies in the fact that the GDI is attempting to access all these widgets at the same time as my threads, and I cannot put locks around THOSE accesses, and in current APIs they need them because of bad design. It is a tremendous waste of resources to force one thread to do all the message parsing AND all the widget updates AND coordinate the data necessary for updating the widgets with background threads -- with ridiculous quantities of flags and messages and locks being used to coordinate all the various unnecessary parts.