onlyonemac wrote:I still maintain that if Microsoft didn't have such a big market presence then they wouldn't be able to sell Windows in the state that it's in, or any of the software that they sell with the approach that they take to getting money from software.
Still you fail to see the fallacy!
Why do you suppose Microsoft has such a large market presence? The market decides what it wants; they buy what they want. What they buy is Microsoft. There was no midnight deal with the deveil - Microsoft just make software that people want.
onlyonemac wrote:Microsoft: write as much code as we can for the next release, and don't debug it thoroughly because we haven't got time for that and it's probably good enough as it is.
That's a guideline (and, as far as I can tell from a page mostly covered in links, toolkit) for developing secure software. What I've read of it just looks like common sense when it comes to security, and it doesn't mean that Microsoft follow it themselves.
And even if they do, I'm not talking exclusively about security vulnerabilities here; I'm talking about all those annoying "when I create a text box in Excel and add three blank lines, I cannot select the text box again" (or whatever it was) bugs. Or the Windows Update that spontaneously stopped working and for which even Microsoft haven't provided a working fix, or the similar situation with Windows Backup on my mother's old office computer.
And it's also ironic that the first heading on a page about security contains the word "experience" - and is a level 3 heading when the first heading should always be a level 1 heading.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
That's why, for example, I don't have any problem investing in Google products
I'm not sure that I would hold Google up as the epitome of sainthood!
Google may have supposedly passively collected information about WiFi networks, but they're still more forthcoming with the security and privacy settings on their operating system. They also take an active part in protecting their users from amlware, unlike Microsoft who just produce a rubbish antivirus product and advise users to pay for a better product elsewhere.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
I don't know why people tend to consider Microsoft's product to be of lower quality than some open source variants. I can't tell you how much I hate .doc files created / edited with something that isn't Word, but that's another topic.
I consider .NET to be one of the top platform for the things it aims to do (and I hope it kills Java, but that's another topic, again).
Even if we look at Windows vs. Other OS, saying that Microsoft has a lower quality product isn't true. You can't split things into "good" and "bad" - and that's especially true when it comes to modern operating systems that try to appeal to such a large variety of users.
I feel like people tend to dismiss Microsoft because their products are (or were, for a long period of time) closed source, and they are just "evil" and that those people don't really have much of an experience with Windows or related products. Here's a fun story. You may be aware of SAL, that little thing Microsoft pushes on people who use C to develop for their platform (especially for driver developers). I work for a company that targets both Windows and Linux platforms, and some people from the Linux department looked weird at code written with SAL asking why would that ever help. And when I tried to explain what it does they dismissed it like "oh, just another thing with which Microsoft controls you". And this didn't come from some low-level wannabe programmer. And it didn't was a joke.
Granted, they have failed products, but they are a big company - it's normal (and healthy) for them to try things out and to have failures. We would say that they are lacking in innovation if they will simply do what will work.
And Microsoft really enforces it's quality and security "guidelines". That's not really possible for user mode applications, but for drivers there's a totally different storry.
Getting back on topic, there are a few things that I find weird about the way Ubuntu on Windows is implemented at the moment. I also don't understand why they said something like "we will implement it like this for now, but will move more of it in user mode in the end". And some things that should work (like installing RVM) simply fail, but this will be big once it is stable.
Alex Ionescu should have a Black Hat talk about this, so that should be fun.
On the security part: Windows is really secure nowadays. On the part of the mediocre solution, that's a default solution intended for users who don't have (or want) something else. Now the problem is that in the past security vendors went YOLO on the OS using all kinds of undocumented stuff. Microsoft put an end to that, but it turns out it's really hard to offer security without those when malware will still use them. And if Microsoft solution also needs to respect the new rules that any other security vendor must respect. There was a bit of a "fight" ar build recently when Microsoft presented a new security solution.
Last edited by zdz on Thu Apr 28, 2016 4:42 am, edited 2 times in total.
onlyonemac wrote:I still maintain that if Microsoft didn't have such a big market presence then they wouldn't be able to sell Windows in the state that it's in, or any of the software that they sell with the approach that they take to getting money from software.
Still you fail to see the fallacy!
Why do you suppose Microsoft has such a large market presence? The market decides what it wants; they buy what they want. What they buy is Microsoft. There was no midnight deal with the deveil - Microsoft just make software that people want.
In case you're not familiar with the history, Microsoft practically forced their products in user's faces right from the beginning, just as they do today. Back in the days of Microsoft DOS, Microsoft had a deal with IBM to sell DOS with the IBM line of PCs, thereby denying users an informed choice of operating system (believe it or not, there were other PC operating systems around then). This continued when Microsoft included their own web browser with their operating system with the express intention of eliminating Netscape, and filed a lawsuit with a PC vendor which was including Netscape in place of the Internet Explorer icon on the desktop of the PCs that they were producing. And today people see the name "Microsoft" all over their computers, and instinctively trust anything with that name on it as being superior to anything else.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
zdz wrote:Alex Ionescu should have a Black Hat talk about this, so that should be fun.
I'm expecting it to boil down mostly to "You're running a secure open-source system on a potentially insecure closed-source base, so you've got no security that you can really trust, just like running an OS inside a closed-source VM." Often those talks focus mainly on the peer-review of the components' source code, and don't trust anything proprietary.
On the other hand, this is a black hat talk, so if they actually try some exploits there will probably be a follow-up from Microsoft saying "oops, we didn't realise how we were comrpomising the entire Linux system by running it on an insecure base", just like the "oops we didn't realise that we were allowing code to execute without user confirmation through ActiveX" thing, or the "oops we didn't realise that running unrestricted code in a desktop gadget could be exploited".
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
onlyonemac wrote:In case you're not familiar with the history
Rest assured that I am familiar with history. Unlike you, I lived that history and I used those products when they were the latest thing.
You forget that IBM - a much larger force than Microsoft - tried to take over the desktop market. They didn't succeed because their operating system - although technically superior to Windows - didn't do what the public wanted. It was nothing to do with Microsoft having a bigger market presence or (obviously) because Microsoft had the backing of IBM; it was simply that Microsoft made the product that was more in line with what people needed. And, like Linux, OS/2 was too complicated for the ordinary person to configure. (This was also true of the server version, which I chose and managed for a number of years; it just didn't do the job as well as Windows server.)
There's no magic to Microsoft's dominance; they just make the products that people want.
zdz wrote:Alex Ionescu should have a Black Hat talk about this, so that should be fun.
I'm expecting it to boil down mostly to "You're running a secure open-source system on a potentially insecure closed-source base, so you've got no security that you can really trust, just like running an OS inside a closed-source VM." Often those talks focus mainly on the peer-review of the components' source code, and don't trust anything proprietary.
On the other hand, this is a black hat talk, so if they actually try some exploits there will probably be a follow-up from Microsoft saying "oops, we didn't realise how we were comrpomising the entire Linux system by running it on an insecure base", just like the "oops we didn't realise that we were allowing code to execute without user confirmation through ActiveX" thing, or the "oops we didn't realise that running unrestricted code in a desktop gadget could be exploited".
So you've never seen a talk by Alex Ionescu before? This guy goes crazy on the details. When he talks about something he usually has something to say.
On the other hand, you consider Linux to be 100% secure? ahahahahha ha... ha...
onlyonemac wrote:Microsoft: write as much code as we can for the next release, and don't debug it thoroughly because we haven't got time for that and it's probably good enough as it is.
That's a guideline (and, as far as I can tell from a page mostly covered in links, toolkit) for developing secure software. What I've read of it just looks like common sense when it comes to security, and it doesn't mean that Microsoft follow it themselves.
And even if they do,
They do. There aren't guidelines alone, which you somehow think are optional. There is time for so-called threat modeling, for security design and code reviews, there are tools to help with said modeling and reviews, there are tools to analyze the code (taking into account SAL) and to fuzz test it (on top of the numerous "regular" tests developed by component/product teams) and so on. I have participated in security reviews, so I know all that stuff (guidelines, processes, tools, tests) exists for real. Microsoft started taking security seriously around Windows XP time, when it became more than apparent that a lot of Windows PCs interconnected with various networks and the Internet isn't gonna be good if Windows security continues to look like Swiss cheese. The cost of Windows security exploits has gone up significantly in the past decade. All thanks to the improvements in Windows security.
glauxosdever wrote:Everything that is stored on Microsoft servers gives Microsoft the «right» to look at it and disclose it to third parties.
In the real world:
Except as customer directs, Microsoft will not provide any third party: (1) direct, indirect, blanket or unfettered access to Customer Data; (2) the platform encryption keys used to secure Customer Data or the ability to break such encryption; or (3) any kind of access to Customer Data if Microsoft is aware that such data is used for purposes other than those stated in the request.
Can you rest assured that they say the truth? Still, I might be wrong about disclosing information to third parties, but still Microsoft can look at it, and you didn't try to prove this doesn't happen either. Let's stop this discussion anyway.
glauxosdever wrote:see how static linking with glibc produces executables of outrageous size
Then don't static link with glibc. I don't think it's designed for static linking, which is probably why executables "have outrageous size" if you static link with it.
Musl is a much better C library. It's smaller and more compact. And static linking with musl adds only the needed functions to executables, unlike glibc, which adds also things that are not needed for that executable.
Also, I don't see how dynamic linking is always better than static linking.
glauxosdever wrote:see how static linking with glibc produces executables of outrageous size
Then don't static link with glibc. I don't think it's designed for static linking, which is probably why executables "have outrageous size" if you static link with it.
Musl is a much better C library. It's smaller and more compact. And static linking with musl adds only the needed functions to executables, unlike glibc, which adds also things that are not needed for that executable.
Also, I don't see how dynamic linking is always better than static linking.
Regards,
glauxosdever
Because it allows you to select what library to use and if you want to use it in a dynamic manner? Again, this isn't a "good" vs "bad" thing as each approach is better suited for different problems.
Also, I don't see how dynamic linking is always better than static linking.
You for real? Pretty nice to not have thirty copies of the same code taking up space on disk and in memory, for starters. There's kind of a reason it's a core feature of every OS ever since the 90s or so.
If you reread my statement, I said dynamic linking is not always better, which implies that sometimes it is better and sometimes it is not.
Static linking happens at compile time, therefore the executable is already ready for execution, so it loads faster. It may also have less symbols. On the other side, functions and data are stored in every executable that uses them (or doesn't use them in the case of glibc), like you said.
Dynamic linking happens at runtime, therefore the executable takes more time to load. On the other side, dynamic linking prevents storage of multiple copies of functions, like you said.
I am aware of the basic positives and negatives of static and dynamic linking. Instead of trying to understand my statement, you implied I absolutely hate dynamic linking, which is not true. Both static and dynamic linking have their uses.
