enigmo

from what I recall (knew some folks on both teams) there was zero shared code. always thought Messenger was the better implementation.

Sounds like an iOS specific limitation? I have a mix of gen1 hardware as well as some newer stuff. Playing from Android phones still works fine even on the old hardware, though I primarily stream from Spotify or from a local Plex server

fwiw it works just fine on Android... it can play files directly from the phone in the Sonos app or by casting from any other app

Sonos is (or was) mostly UPnP with some extensions... so for discovery they used SSDP https://en.wikipedia.org/wiki/Simple_Service_Discovery_Proto....

I messed around with their stack and internals for a while about ten years ago... some remnants remain

https://github.com/NathanHowell/Sonority/tree/master/

https://github.com/NathanHowell/Sonority/tree/core/

https://github.com/NathanHowell/upd2

pretty close to how our Zoom conference rooms are setup... iPad controller + Mac Mini + Revolabs UC

Did they have the STE title or SDET? When this happened it wasnt like there was 100% automation in place so developers, architects, SDETs, had to pick up the slack. I personally got stuck verifying bug fixes for our components (kernel stuff and supporting user mode services) in various languages I don't speak (particularly fun for left to right languages) just to get the bug count down. That team had something like 20 STEs that got the axe post beta 2.

MS abolished manual testing (STE) positions prior to Windows Vista being released, somewhere around beta 2 or rc1. Vista probably suffered from this but Windows 7 didn't.

a bunch of them now work at Google on the Brain/Tensorflow team. definitely was an odd move.

As a maintainer of a >130kloc Haskell codebase spanning thousands of modules and hundreds of packages, I avoid TH primarily for one reason: slow builds. Painfully slow.

For cases where GHC.Generics is an option, I always take GHC.Generics over TH. Yes, Generics can be slow at times too but this somewhat controllable with various GHC_OPTIONS. Either way, there is no loader and interpreter overhead... and a lot of Generics code compiles in less time than it takes TH just to load `text` or `aeson` ;-).

Other reasons:

  * Some TH libraries add implicit dependencies that are not tracked by the build system
  * GHCi/TH's loader is different than the OS loader, sometimes causing failures if a TH dependency touches C++ libraries
  * No cross compiling ability... not an issue for me but it's painful for those targeting Javascript (via ghcjs), ARM or smaller x86 embedded systems

I've seen Stack download prebuilt binaries for some packages but build others... always having prebuilt versions of text/aeson/vector/lens/etc would definitely speed up resolver upgrades.

Depends on how predictable the branches are. LLVM used to use CMOVs whenever possible but I believe this was changed a few years back to generally improve performance.

See a related bug in GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309

"conditional moves instead of compare and branch result in almost 2x slower code"

Taken to it's logical extreme: k-Ary Search on Modern Processors

https://people.mpi-inf.mpg.de/~rgemulla/publications/schlege...

As SSE/AVX registers get wider and wider you might as well compare an entire cache line (or two) at a time. But the overhead of building the level order k-tree means you need to do a whole lot of lookups for each insert... so it doesn't apply to that many problems. Unless you're building a search engine. Then it applies a lot.

Turns out crawlers spend a lot more (wall clock) time waiting for a complete response than they do requesting it. However, scheduling is a much (much, much, much) harder problem to deal with than async i/o but it's not what many people here need to worry about.

It has TransmitFile and TransmitPackets: https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...

They were in use (at least TransmitFile was) by IIS long before http.sys was conceived.

PySpark does not run Python code on the JVM. It uses py4j and it is slow as molasses. This has the benefit of supporting native Python libraries like NumPy. If you're not using such libraries you'd be better off using a JVM language, including Jython.

Why not use Ceph? There are solid Haskell bindings for RADOS: https://github.com/anchor/rados-haskell

eBay's frontend is mostly Java on Windows. Many thousands of servers running Windows. Their search grid was on Solaris but has migrated to Linux in the last year or so (2013?).

That was the case in 2009. GHC 7.8.3 is doing better now for regular Haskell code in the loop.

    main :: IO ()
    main = do
      let go :: Double -> Double -> Double
          go !i !s
            | i < 100000000 = go (i+1) (s + 1/i)
            | otherwise = s
      printf "Almost infinity is %g\n" (go 1 0)

Inner loop assembly:

    LBB0_4:                                 ## %c3Sk
      movaps	%xmm3, %xmm0
      divsd	%xmm1, %xmm0
      addsd	%xmm3, %xmm1
      ucomisd	%xmm1, %xmm4
      addsd	%xmm2, %xmm0
      movaps	%xmm0, %xmm2
      ja	LBB0_4
      jmp	LBB0_2

Have you considered using a pre-existing distributed filesystem like Ceph or even HDFS instead?

i made a similar call a few years ago (thanks DE) and it was free ;-)

It's not really that novel. When I wrote a Sonos client (2007) there were a few out there already. Getting things working did involve a lot of time in Netmon (nee: Wireshark), and reading UPnP specs.

https://github.com/NathanHowell/Sonority https://github.com/NathanHowell/upd2 <-- update image extractor

A few of us went a bit further, found some telnet backdoors and cracked the root password.

It works for most kernel handles, sockets might be a little more normal starting with Win7 but I stopped doing Windows development around then.

Here are the official docs: http://msdn.microsoft.com/en-us/library/windows/desktop/ms72...

Windows has supported this for ~14 years too.

I know of the JIRA, thanks. I'm aware that it is being actively developed, but I don't necessarily believe that activity is progress. Keeping a few different players in the mix helps keep everyone focused on progress.

I'd like to see other distributed filesystems catch on too. HDFS has a lot of room for improvement.

time (sadly) isn't comparable to Joda Time.

Definitely... and _way_ more IOPS.

324 disks takes up most of a row. When we had to do service maintenance in Canyon Park (fun with NT 3.51 and 4.0, before the days of Terminal Server) I'd walk over to TerraServer and admire it's enormity.

We've been using it for about 15 months now without any problems with RADOS. Last winter we had some data loss with CephFS and needed to rebuild the filesystem from backup, but CephFS is unsupported so it was somewhat expected. I think the issues came from the Linux kernel client (circa the 3.2 kernel iirc), so we switched over to the FUSE client instead and have been on that since.

Good news is that performance is much, much better with 0.61 than prior releases. Both for RADOS and CephFS. We'll probably upgrade to 0.67 in the next few weeks and it's probably time to upgrade to the 3.10 kernel as well for btrfs fixes and to kick the tires on the kernel fs client again.

I've been looking at a mSATA SSD and a low profile pcie card for our Ceph cluster to free up the OS/journal drive slots for more 4tb spinning disks.