recentpopularlog in


« earlier   
Microsoft open sourced msbuild : programming
–]MasterOfSlack 131 points 14 hours ago*

Until it breaks at which point you are literally up shit creek even with symbols and windbg which we've been numerous times. Stuff is only quality until it breaks and you can fix it.

Race condition in ReaderWriterLockSlim take out 40 production nodes? Yep. Forcing a minidump during the race condition fails 95% of the time. No idea of the solution as the stack for all threads goes into the NT syscall void.

Called up partner support: after multiple emails bouncing back to validate our contract, guy in india has no idea what is going on and doesn't know who to contact.

Solution: spent 12 hours overnight rewriting the fuck out of everything that touches it and hope it goes away. Which it did. Remainder of life spent praying that something else doesn't fall off.

If this blew on a Unix platform, it's a 5 min job with gdb/objdump and the source code...

NOT quality as a platform. This is real in the field experience from me.

Edit: just to say that open sourcing it is the right way to deal with this. More visibility of the black box is what we need but it's not going to be valuable for any of us not doing greenfield. Even our simplest bits of platform are still well tied into proprietary assemblies. Start again is where we're at and we might as well pick dropwizard or rewrite it all in python or go next time; the cost is the same if not less.

Edit: thanks for the first gold - unexpected!
[–]MasterOfSlack 36 points 14 hours ago*

That's one of the problems. I can forgive a single incident but the real underlying problem is the frequency that problems occur, the accumulated cost of dealing with them and the lack of improvement at handling them. In fact it has got worse. The organisation appears to be in abject chaos due to restructuring. This is despite the "new Microsoft" we see in the press. The consequential cost to businesses is pretty high. It's beyond operational expenditure - it's simply written up as loss and risk.

These are all huge black crosses against getting budget to renew a pile of platform licenses or start a greenfield or rewrite against a platform.

That's where we're at and why SQL 2014 upgrade budget didn't get signed off but a deep dive into open source technology platforms did.
TOP  Inspiration  UNIX  Linux  *BSD  System_Administration  System_Programming  Debugging  Windows  platform  criticism  PROs  CONs  gdb  objdump  higher_quality 
march 2015 by snearch
Berkeley’s RISC-V Wants to Be Free
“There are two major products that came from Berkeley: LSD and Unix. We don't believe this to be a coincidence.” – Jeremy S. Anderson.
LSD  UNIX  *BSD  Berkeley 
december 2014 by snearch
How we've made Raptor up to 4x faster than Unicorn, up to 2x faster than Puma, Torquebox
The libev event library

As mentioned before, our builtin HTTP server is evented. Writing a network event loop with support for I/O, timers, etcetera is quite a lot of work. This is further complicated by the fact that every operating system has its own mechanism for scalable I/O polling. Linux has epoll, the BSDs and OS X have kqueue, Solaris has event ports; the list goes on.

Fortunately, there exist libraries which abstract away these differences. We use the excellent libev library by Marc Lehmann. Libev is very fast and provides I/O watchers, timer watchers, async-signal safe communication channels, support for multiple event loops, etc.

Libev should not be confused with the similarly-named libevent. Libevent is also an excellent library and is much more full-featured than libev. For example, it also provides asynchronous DNS lookups, an RPC framework, a builtin evented HTTP server, etc. However, we don’t need any of those extra features, and we were confident that we can make an HTTP server that’s faster than the libevent builtin HTTP server. We’ve also found libev to be faster than libevent thanks to libev’s smaller feature set. This is why we’ve chosen to go with libev instead of libevent.
programming  asynchronous_event_processing  OS_X  Linux  *BSD  libev  libevent  epoll  networking_hardware  kqueue 
november 2014 by snearch
The Plan-9 Effect or why you should not fix it if it ain't broken
One of the major problems with Plan-9 was that AT&T and the people behind Unix, while they were incredible scientists and programmers, they were not used to create commercial software and AT&T has never been in the software business. This, I have to admit, can sound as a blasphemy but it is the way it is. They used software and they used to produce internal software to run their high end network appliances but they never created software to be sold to someone else and it never was major source of revenue as, for instance, Sun, IBM and Microsoft used — or still use — to do. This just means that they never had a sense of what could have been needed into the outside world. For instance, Sun Microsystems used to and that is the reason why RPC was created. They realized that people struggled with network programming and they saw in creating an abstraction layer a commercial opportunity: "Hey people, SunOS has this cool thing that permit me to do network applications without messing up with sockets! Better moving to SunOS".

Moreover, in Plan-9, many of the "good old things" were removed and a lot of incompatibility was introduced in the system with respect to the other Unixes. This prevented many different companies to even start thinking of porting their applications to Plan-9. What is the point of trying to port your software, doing a huge amount of work, to a new platform if you do not know if that system is going to succeed? This is the classical chicken-egg problem: an operating system is worth only for the amount of applications running on it and nothing more. If a system is new, you need to be able to guarantee that you are going to have an ecosystem of applications that will make the operating system valuable. There are only two ways of doing this. The first one is to create a system that is as compatible as possible with the existing ones — and this is the case of Unix, POSIX and Motif. The second one is to create the ecosystem yourself in order to improve the value of the product — and this is the case of Microsoft Windows and the Office productivity suite.
*NIX  *BSD  Plan_9  CONs 
september 2013 by snearch

Copy this bookmark:

to read