The primary reasons people use a Windows operating system are backwards compatibility and familiar user interfaces. Nobody is going to bother to learn that swiping bullshit. If M$ wanted to make some user-friendly, social media cancer OS, then it should have just revamped its tablet PC operating system, which severely lacks original features.
Name:
Anonymous2011-09-15 6:06
Why does it look like the Xbox 360 interface? I mean that's good if you only have a dpad and one button to do most things but I was under the impression Windows users also used a mouse and a keyboard.
>>8
As the average age of a Windows user approaches 50 years, more and more of us find ourselves anxious and distressed by lots of buttons and input devices. Which one of the 102 keys on the keyboard should I press to send an e-mail? Or should I use the Mouse somehow?
Name:
Anonymous2011-09-15 8:58
looks good, personally I like tiling DE but I really don't give a fuck since I'm not one of their clients
UI is I/O that has to be as fast as you, and you're constantly becoming faster, and UI is I/O that has to be as good as you, and you're constantly becoming better. This eyecandy, I will never be able to *use*. Now MS goes and rapes even tiling.
Name:
Anonymous2011-09-15 15:11
>>1
It makes me feel conflicted. 1) As a user, it is a step in the right direction for their UI. 2) As a programmer, it means that all the applications that I have to support from XP and Win7 are going to have to be rebuilt to not look like dated shit on Win8.
First KDE, then Gnome and now Windows. Who are the fucking fags who keep coming up with shit ideas for UIs?
Name:
Anonymous2011-09-15 16:02
>>18
KDE is not that bad. It's still quite normal windows+icons+panel+menu and most of the crap can be turned off, themes changed and they even have classic menu.
Gnome, on the other hand, is complete crap. Long live Xfce.
User Interface Designers are, together with MBAs, the cancer that is killing modern software. I can say will all confidence most software would be better without them.
Also, the way Microsoft doesn't realize why their own products are popular is amazing. They see somebody 10 times smaller doing something else and say "we want in too" like some sort of hungry hyenas, waste billions of dollars, fail to monetize it while killing the competition, and then bail out a few years later.
Name:
Anonymous2011-09-15 17:51
How do you guys feel about Google's new UI?
Name:
Anonymous2011-09-15 18:00
>>22
It fits their new product, Google+. The design feels solid and attractive.
Ideal windowing manager should abandon the "title" widget, cuz it takes space and doesnt provide any useful info or functionality. You can faster move windows by alt-clicking on them.
Name:
Anonymous2011-09-15 20:11
>>25
And some integrated system-wide Lisp support would be great. Promise, when I see it, I'll buy Windows.
>>28
I have five "buttons" on my mouse -- scroll up, scroll down, scroll click (middle click), right click and left click. I'm not going to remap scroll click just to watch porn.
Also, it would be great, if MS remove their crappy MSI, install shield, registry and replaced them with RAR archives, so I could just unpack programs where I need, like in the times of MSDOS, without all these retarded "Wizard" dialogues.
Name:
Anonymous2011-09-15 23:46
>>31
Also-also, no need for DLL files anymore: every program should be build in monolite exe. Today we have abdundance of RAM anyway.
Name:
Anonymous2011-09-16 0:02
>>31>>32
Because "C:\Program Files", Registry and DLLs are basically a form of static typing.
DLLs will be gone along with all dynamic libraries when 16-32gb of RAM will be standard on entry level computers.
It was invented to conserve memory space, most of the time its just a lousy alternative to static linking.
I've seen many Linux apps switching to static to reduce errors and dependencies.
>>35
Last time I got compiled code for Linux, it complained of missing libC++-14.88.so or something. When I tried to force it to use current version, it just segfaulted.
Name:
Anonymous2011-09-16 1:55
>>35 DLLs will be gone along with all dynamic libraries when 16-32gb of RAM will be standard on entry level computers.
MSDOS had 16gb of memory?
>>20
I don't know nor care. Gnome was always ugly and poorly configurable while being just as big and bloated as KDE. No one in their right mind would use it.
Name:
Anonymous2011-09-16 2:23
>>35
>DLLs will be gone along with all dynamic libraries when 16-32gb of RAM will be standard on entry level computers.
>16-32gb
>Not writing GiB
wat
Name:
Anonymous2011-09-16 2:30
The day that shared libraries and dynamic linking & loading dies will be the day that Ulrich Drepper got hit by a bus.
But I like DLLs. I hate having to see the same code when I'm disassembling some closed source software, and I hate seeing many extra megabytes of library code appended to a few kilobytes of actual code. Of course, I can make signatures for statically linked libraries, but that's not the point.
The major issue with them is properly dealing with versioning, but there are multiple working solutions to this.
Name:
Anonymous2011-09-16 3:36
>>43
That is why static code analysis sucks and it cant solve halting problem. Use emulator and debug code interactively.
>>44
You don't need to solve halting problems to implement adequate static code analysis. Go see the other thread where a wrench was thrown into your proposed problem. You need only consider the worst case path, and therefore you can collapse all conditional logic and determine an upper bound.
Name:
Anonymous2011-09-16 3:48
>>45 You don't need to solve halting problems to implement adequate static code analysis.
I packed my code using GZIP. Try ANALysing it, faggot.
>>44
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>44
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>44
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>44
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>51
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>52
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>53
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>54
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals). oh and check my doubles
>>55
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals). oh and nice doubles
>>56
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>57
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>58
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).
>>59
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).