|
|
|
|
|
|
by formerly_proven
1797 days ago
|
|
|
Yet Microsoft's tools for C/C++ don't hold up. Visual Studio is stuck in the early 2000s (and frankly the UX is horrendous), everything is packaged in weird GUI tools, the entire environment is practically hostile to automation. The VS debugger is probably one of the best pieces, everything else is simply outclassed. Debuggers have also been supplanted for many uses by other tools, of which Microsoft has few and all of them are annoying to use at best. I really wouldn't want to be a developer for Windows that has to cope with debugging e.g. memory issues (on Linux, you put "valgrind" in front of your command, and it tells you the exact line number containing the error 98.4 % of the time -- yes MS has a number, that is, too many, tools to debug various issues, most of which are arkane at best, like gflags). The default for scripting on Windows is still batch, which is simply insane (since batch was designed within the confines of a single user single "process" environment with no memory). And this is just lacking in the basics department. We're not even talking about Windows coping very badly with development workloads like reading/writing many small files (which is a design flaw in the NT kernel and will not be fixed, ever). Of course, if you don't use any of Microsoft's stuff, there really isn't anything wrong per se, just annoyances (slowness, spying and other user-hostile behavior from the OS); IntelliJ is IntelliJ, Linux or Windows matters very little if you live inside it. Edit: It shouldn't be a surprise that Visual Studio is essentially abandoned by Microsoft. Do you abandon good things? You don't. |
|
|
Not the kernel, but ntfs.sys. It is a design limitation of NTFS and was a tradeoff for something else. At the time NTFS was designed, high frequency reading and writing to small files was not at all common.
This does not exist on FAT/32/64 partitions, though there is always a per-file overhead on any filesystem, and FAT filesystems have their own problems.
IO performance tools don't seem to test reading and writing to a large number of small files; they tend to want a single large file and they test performance to and from that file. That's by design, and that means those tools don't find filesystem design limitations, or allow you to measure certain types of performance on a per-filesystem basis.
> Edit: It shouldn't be a surprise that Visual Studio is essentially abandoned by Microsoft.
Again, not true.
No one can know everything that MS is doing, of course, but the number of people who think they do is quite high. I am not referring to the person who made the comment I am replying to, by the way. Generally I just see a lot of things about MS or MS tools that are stated as fact and are entirely incorrect.