recentpopularlog in

*BSD

« earlier   
In Unix Everything Is a File | Hacker News
pjmlp 1 day ago [-]

Any UNIX old timer knows that actually:
In UNIX everything is a file, except when it is not.

reply




epx 1 day ago [-]

I like the Linus Torvalds' interpretation: that (almost) everything is actually a file descriptor. The few things that are not, like fork() returns, are subject to criticism (DJB wrote about how fork() should return an fd, I just couldn't find the URL right now.)

...
ernst_klim 22 hours ago [-]

>if Plan 9 had taken off in the 90s
Plan9 is a joke, file abstraction is a ridiculous idea. File abstraction is terrible for anything beyond storing information.

It sucks for multimedia, IPC, input. Unix showed that, escaping from file abstraction in any domain (except networking, maybe). That's why we use d-bus instead of pipes, opengl instead of writing buffer etc. People need disposable, modular and introspectable APIs, like in mirageos, lisp machines or smalltalk OSs, not a ridiculous file crap.
*NIX  *BSD  Linux  TOP  Inspiration  Torvalds_Linus  FUN  Insightful  higher_quality 
25 days ago by snearch
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

Copy this bookmark:





to read