Future instruction set: AVX-512 - <AUTHOR> http://agner.org/optimize/blog/read.php?i=288

<comment><USER2> The AVX / SIMD part of x86 instruction set is probably the most understandable subset to focus on learning! And i'm very excited about AVX-512

I'll actually going to be spending some of my time over the next year adding proper SIMD support (including all the shuffles) to the main Haskell compiler, GHC!

Theres some really interesting constraints on the SIMD shuffle primops that need some type system cleverness to compile correctly!

Namely, you need to know "statically, at code gen time", the shuffle constants that are given as "immediates" to the instructions! Normal values don't quite have the right semantics, and accordingly the simd intrinsics in C compilers kinda lie about the types they expect (ie if you give them a variable of the right type, they'll give you an error saying they need an actual constant literal).

tl;dr I'm going to make sure the GHC (and haskell) can support AVX 512 by the time thusly equipped CPUs are made available

<comment><USER3>
      > Namely, you need to know "statically, at code gen time",
      > the shuffle constants that are given as "immediates" to
      > the instructions!

Can you clarify where the extra difficulty is?

I'm ignorant of GHC, but I'd think that from the compilers POV all that matters is that that the operand is a constant. Then it's just a matter of putting the value in instead of the name. In GCC inline assembly, you can use the poorly documented '%c' prefix to have a number treated as an immediate, so I'd guess this must be possible internally too. Also possibly worth noting is that unlike the others, PSHUFB works from a register rather a value encoded into the instruction.

<comment><USER2> There's more than one shuffle instruction, in fact there's quite a few! You're right that some can take register args, but those aren't the ones I care about as much.

You're right, there are hacks in c that handle that. My goal for ghc is to actually have a systematic solution for handling any sort of constant literal expression at compile time. This includes making it easy to add new primops that require compile time literal data.

There's some interesting implications if you want that restriction to be typecheckable! This includes having a "static data kind". Part of why you want that is also because ghc is great at common sub expression elimination, and I consider any implementation strategy that could be broken by compiler optimization to be unacceptable.

[edit to clarify: just naively using normal literal values would likely be subject to cse optimization, and having code gen need to look around to lookup a variable rather than being a localized process is somewhat horrifying]

One particular end goal of mine is this: SIMD isn't that complicated, and it's really easy to experiment with (but only if you can cope with c). I want to make experimenting with SIMD much more accessible.

Interestingly enough, the notion of static data I want seems like it might be an especially strong version of the notion of static data that Cloud Haskell (the distributed process lib) would like. So there may be some trickle Down there!

One really cool optimization having a proper notion of static literals might enable is making it much easier to generate things like static lookup tables and related data structures that are small and perf sensitive

Edit: also if you want to try and stare at the source for a serious compiler, ghc (while huge) is pretty darn readable. Just pick a piece you want to understand and stare at the code for a while!

Edit: I should add that Geoff mainland has some great preliminary work adding experimental simd support to ghc that's in head/ pending 7.8. That said, ghc support for interesting simd won't be ready for prime time till 7.10 in a yearish

</comment></comment></comment><comment><USER4> Seems to me like Intel and AMD aren't very forward thinking, adding new instructions and registers every year or two. As if the x86 instruction set wasn't bloated enough, now they're going to have instructions with 4-byte prefixes, and new registers you can only access with AVX. What's next after that, AVX-1024 with 6-byte prefixes? Meanwhile this renders MMX and SSE sort of redundant. Seems to me we might be better served with some kind of vector coprocessor and instructions that can operate directly on large vectors in memory, instead of doubling the size of the vector registers all the time and making x86 an ever harder target to generate efficient code for.

Maybe this is another area where ARM can beat x86. Have a better planned out vector instruction set that can be expanded without adding hundreds of new instructions all the time, and more compact machine code.

<comment><USER5> _Meanwhile this renders MMX and SSE sort of redundant._

It's an evolution of the same SIMD ideas. Yes, the newer variants do render the older variants redundant, but hang around because code might use it.

MMX - SIMD, integer only, reused existing floating point registers making it a PITA that often didn't even payoff because of the expensive state switching between MMX and floating point.

SSE - starting as floating point SIMD with its own 128-bit registers. Evolved through SSE 4.2 with more instructions (functionality in hardware), flexibility (e.g. operate on 4 singles or 2 doubles or...) and the addition of integer functionality.

AVX - Double the size of the vector registers, adding more of them and lots of new instructions and functionality. The successor of SSE, at least on the floating point side. AVX2 brought the integer functionality.

AVX-512 - Double the size of the vector registers again. 16 single float operations in one go.

 _Maybe this is another area where ARM can beat x86. Have a better planned out vector instruction set that can be expanded without adding hundreds of new instructions all the time, and more compact machine code._

This kind of sounds like baseless griping. Unless you write a compiler, why do you care? Do you really sweat the instruction prefixes?

<comment><USER6> I wish that Intel would have spent some transistors on an arbitrary precision decimal arithmetic floating point unit. That would have helped scientific processing but in the past has been 'too expensive' in terms of transistors to implement. Now that we have more transistors than we know what to do with, seems like that should be revisited.

Then generalize the vector coproccessing abilities of the GPU and that would be a pretty flexible base to work from.

<comment><USER7> Why does scientific computing care about decimal arithmetic?

<comment><USER6> Same reason accountants do, numbers like .1 aren't approximate repeating fractions in decimal representation.

<comment><USER8> Citation needed, please. I don't know where nature is decimal.

<comment><USER6> Actually its more fun if you just "do the math" and its a fun computer science problem:

0.1 is 1 / 10, fractional binary bits are 1/2, 1/4, 1/8, 1/16 ... find a combination of bits that represents 0.1.

If you want a very long treatise about how binary sucks for doing arithmetic wander over to [http://speleotrove.com/decimal/](http://speleotrove.com/decimal/)

<comment><USER7> Right, and I can see why that's a problem in accounting, but why does it matter for scientific computing? I do a fair amount of stuff that could be called scientific computing, and I just use doubles. If I need to keep track of uncertainty or propagate errors, I normally use Gaussians as the representation (not "significant figures" as would be implied by using decimal).

<comment><USER9> It almost never matters in scientific computing. Doubles give us the equivalent of almost 16 digits of accuracy, and that's more precision than we know any physical constant to. You're right that the world isn't decimal, and switching to decimal encodings actually reduces the effective precision of any computation.

<comment><USER10> There's a reason they're called the natural numbers. Nature doesn't have to be decimal for decimals to be useful (the question that started this debate), it just has to be rational. Many many many parts of nature are rational, and sometimes we need to deal with them in scientific computing. DNA sequence processing comes to mind.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Is there a good place to begin to learn about this stuff from the ground up? Maybe a user friendly compiler written for the purpose of education?

<comment><USER12> The shallow end of the pool is simple RISC CPUs e.g. Atmel 8-bit AVR. The complete instruction manual is something like 160 pages (compare to x86 at 3k+) and there are tons of beginner resources for doing assembler on those chips.

<comment><USER13> There's more structured material for MIPS than AVR. Plus the AVR has some funky memory maps and modes.

<comment><USER14> This all time classic from MIPS is a good starting point: " _MIPS R4000 Microprocessor User 's Manual_" [1]

[1] [http://groups.csail.mit.edu/cag/raw/documents/R4400_Uman_boo...](http://groups.csail.mit.edu/cag/raw/documents/R4400_Uman_book_Ed2.pdf)

</comment></comment></comment></comment><comment><USER15> And yet phones are already doing real-time 4k video encoding.

In other words, since a lot of compute intensive scenarios are already being served by less general purpose hardware, what are the most recognizable scenarios where AVX-512 will make a big difference over AVX-256?

I know video encoding can be an integer only algorithm while AVX seems to help floats more but still...

<comment><USER16> Which phone can do realtime 4k encoding? Can you tell me which SoC it uses?

Edit: It's the Acer Liquid S2, with Qualcomm Snapdragon 800 SoC

<comment><USER17> All Snapdragon 800-based phones, and there are quite a few of them, and there will be more in the coming months (and of course later even more chips doing the same). Right now it's the one you said, LG G2, Sony Xperia Z1, Samsung Galaxy Note 3, and soon the Nexus 5.

Now I'm not 100 percent sure if every single one of them has that as a _user- centric_ feature (maybe they didn't enable it), but the chip supports 4k video recording.

</comment></comment></comment><comment><USER18> The mask registers that can turn off operations on individual elements of a vector reminded me of CUDA. It might be possible to emulate individual "threads" on these pretty easily.

Does OpenCL have a similar threading concept? I don't know much about it, sadly.

</comment><comment><USER19> I really wonder what this is for. Isn't AVX-256 code usually already limited by memory bandwidth? There are design tradeoffs between memory latency and memory bandwidth and in order for Intel CPUs to keep their advantage in high single threaded performance they have to lean towards the low latency side of things.

Is this aimed at Larrabee?

<comment><USER20> SKUs of Haswell with the GT3e graphics configuration include 128mb of on package DRAM, which is intended to give more memory bandwidth to the GPU, but it also acts as a cache for the CPU.

Based on what you're saying, it seems as though AVX-512 and future models with larger, faster embedded DRAM might play very nicely together.

<comment><USER19> I should have been clearer. I was talking about the cache hierarchy and CPU memory pipes. I suppose there's a divergence in main memory too, with CPUs using DDR3 and GPUs using GDDR5, but as you say you can just throw cache at that problem.

</comment></comment></comment><comment><USER21> _Floating point vector instructions have options for specifying the rounding mode and for suppressing exceptions._

That's huge.

</comment><comment><USER22> Is there any x86 instruction set that supports quadruple precision floating point numbers? If not, why not? Is it not useful enough?

<comment><USER23> Where exactly is it useful? Double is already an overkill in all multimedia operations, and finance folks use fixed-point anyway.

<comment><USER24> Quadruple (or higher) precision is needed in many scientific applications.

<comment><USER25> Do you know of any specific applications? "many" seems like an extraordinary claim. I'm under the impression that quad precision is fringe. Double precision support on GPUs is fairly recent.

<comment><USER24> Sure. Just for a start, some of David Bailey's papers ([http://www.davidhbailey.com/dhbpapers/](http://www.davidhbailey.com/dhbpapers/)), e.g. "High-Precision Arithmetic: Progress and Challenges" and "High-Precision Floating-Point Arithmetic in Scientific Computation" show some concrete examples. You will find many others by searching for papers containing the words "quad double arithmetic", "high precision arithmetic", "multiple precision arithmetic" or similar terms. Most applications are probably in physics, and of course in pure mathematics.

</comment></comment></comment></comment></comment><comment><USER26> This might well be a dumb question, but why don't we have 128 bit processors?

No advantage? Crazy expense?

<comment><USER27> At some point, you need to ask what you mean by 128 bit. When people talk about an 8 bit, 16 bit, 32 bit, or 64 bit processor, they are actually generally conflating two or more things. There's the size of general purpose register, the size of the data bus (how much you can load from memory in a single transfer), the size of the address bus (how many lines you have for addressing RAM), and the size of pointers. In many machines, these have been the same, though for example, 8 bit processors frequently had 14 or 16 bit addresses and busses so they could access up to 16 or 64k of memory; but there's also, for example, the 68008 with 32 bit registers, a 16 bit address bus, and an 8 bit data bus.

So, when people talk about 32 or 64 bits, they generally mean two things: the size of general purpose registers, and the size of addresses.

There's basically no need for addresses beyond 64 bits, at least for quite some time. With 64 bits, you can address 16,384 petabytes (16 exabytes) in a single process. Since the biggest single machines I can find these days support a maximum of 4 TB of RAM (if you filled it with 32 GB DIMMs that aren't yet available), we have a long way to go before you will need more than 64 bits of address space.

Furthermore, increasing address size can hurt performance. If your pointers are all 128 bit, they take up twice the space as 64 bit pointers. There have already been plenty of workloads that show a reduction in performance when ported to 64 bit machines, just because the 64 bit pointers fill up so much valuable cache space. In fact, for this reason, Linux even has support for the x32 ABI, which uses an x86-64 processor in 64 bit mode but only uses 32 bit pointers, so they can take advantage of extra registers available to x86-64 without paying the price for the larger pointers. [https://en.wikipedia.org/wiki/X32_ABI](https://en.wikipedia.org/wiki/X32_ABI)

So, there's no benefit to 128 bit addresses and lots of potential downside, so it's not going to happen for quite some time. How about for data, though?

Well, most software doesn't really need to work with integers or floating point numbers larger than 64 bits, anyhow. For lots of applications, 64 or even 32 bits is sufficient. Public key crypto can frequently take advantage of large integers, though it generally needs even bigger integers, like 2048 bits, so you generally have to do bignum arithmetic anyhow.

Lots of the gains that you get from working with larger types come from working on vectors of smaller types. But for those purposes, chips have had 128 bit registers for quite some time. SSE, introduced in 1999, included 128 bit vector registers, which could be treated as 4 32 bit integers (AltiVec on PowerPC had introduced the same idea a few years earlier; the idea of SIMD has been around in supercomputers for many years). Later extensions like SSE2 expanded their use to allow you to treat them as two 64 bit floats, two 64 bit integers, 8 16 bit shorts, and 16 8-bit bytes.

So, for the only use case for which it's particularly valuable, working on vectors in aggregate, we've had 128 bit registers for quite some time. We've had 256 bit registers for a couple of years now in the form of AVX. Now this promises to expand those to 512 bits. There's no good reason to expand your addresses in the same way; at that point, you're just wasting space.

<comment><USER28> Up voted. Although 16 exabytes is less overhead if you are memory mapping persistent storage rather than just RAM which makes increasing sense with SSDs. 64bit addressing is still plenty for most scenarios for some time to come though even if this approach is taken.</comment></comment></comment>


UK politician cured his smartphone addiction by buying a BlackBerry - <AUTHOR> http://www.engadget.com/2015/04/02/ed-miliband-blackberry/

<comment><USER2> Two years ago, i did the same thing!</comment>


FSF to Launch Code Hosting - <AUTHOR> https://lwn.net/Articles/813254/rss <comment><USER2> I don't get it. They say they'll continue to support Savannah, so what is this for?</comment>


Listening to Caltrain: Analyzing Train Whistles with Data Science - <AUTHOR> http://svds.com/post/listening-caltrain

<comment><USER2> I don't get it. Why don't you just have your app ask permission to look at the phone GPS and have it anonymously phone home whenever they go to a Caltrain station and start moving (or fail to move) at a train-like speed along the Caltrain route?</comment>


ND4J: Scientific Computing on the JVM - <AUTHOR> https://github.com/deeplearning4j/nd4j <comment><USER2> Hopefully this can pave the way for deep learning and data analysis for Scala/Java. It's really frustrating having to use a subpar and inexpressive language like Python because of the huge data science network effect.

Or if Julia could get more libraries (it's maybe 25% there, which isn't bad), that would be pretty great as well.

<comment><USER3> > It's really frustrating having to use a subpar and inexpressive language > like Python because of the huge data science network effect.

I'm afraid that the "network effect" is gonna continue for the years to come. NDArray is not the only thing you need for data analysis. DataFrame, statistical functions, and data visualization packages like matplotlib and ggplot are all indispensable components in a data analysis workflow. It has taken thousands of contributors a decade to build a solid ecosystem for data science in Python or in R. It's just unlikely for Java to become a mainstream data science language overnight.

I'd say if you are looking for a statically typed language for deep learning, C++ is probably a better bet than Java for now.

<comment><USER2> I don't really want Java as a data science language, but Scala would be a perfect fit.

There's already a nice data frame library that I helped develop at my old company called Saddle. Now we just need some quant finance libraries (like the excellent zip line, pyfolio, and alpha lens), some industrial NNs, optimization libs (like cvxpy), and something like scipy.

Is this ever going to happen? Probably not, but a man can dream..

</comment></comment></comment><comment><USER4> This moved into the deeplearning4j monorepo: [https://github.com/deeplearning4j/deeplearning4j/blob/master...](https://github.com/deeplearning4j/deeplearning4j/blob/master/nd4j/README.md)

</comment><comment><USER5> I'm eagerly awaiting their sparse matrix support. It's unbelievable that the entire JVM doesn't have a single comprehensive, production quality sparse matrix library [0]. This is one of the big things keeping my machine learning in Python.

<comment><USER6> Check out Neanderthal[0], it seems to have support for some subset of sparse matrices and it's faster than ND4J[1] to boot.

[0]: [https://neanderthal.uncomplicate.org](https://neanderthal.uncomplicate.org) [1]: [https://dragan.rocks/articles/18/Neanderthal-vs- ND4J-vol1](https://dragan.rocks/articles/18/Neanderthal-vs-ND4J-vol1)

<comment><USER5> Yeah, Neanderthal is great (I'm a Clojure a user). It's got support for structured sparse matrices (like Toeplitz) the last I checked, but not general CSC/CSR matrices.

</comment></comment></comment><comment><USER7> William Kahan, the father of IEEE floattig point arithmetic and one of the main references on numerical errors, has some bad thing to say about doing floatting point computations on the JVM : [http://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf](http://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf)

An nd array library could be great for machine learning but it is probably not the place where you want to do numerical simulations.

<comment><USER8> Honest question, how much is this about Java and not the JVM and its from "July 30, 2004", is it even relevant now 15 years later ?

<comment><USER9> Everything except operator overloading also applies to the JVM... But equally well to python. Basically, the complaint is you don't get any of the hardware fp stuff like traps and signals and all of the math is slightly unportable because it gives different answers on different machines, but these are well- known issues.

<comment><USER7> There is also the fact that intermediate operation between floats are done in float precision and not double precision (as would be the case with C). It might be the behaviour one would expect but it can lead to serious degradations of a numerical computation.</comment></comment></comment></comment>


BBC Horizon - Psychedelic Science - DMT, LSD, Ibogaine - <AUTHOR> http://www.youtube.com/watch?v=d74ZwkOzXB4 <comment><USER2> At my studio back in Sydney we had several San Pedro cactuses (they contain mescaline and are identical to Peyote in effect) growing on the balcony. One night after taking everyone out for drinks we went back to the studio and got into them. I was lounging around talking with one of my business partners about how we didn't think it was really going to kick in. A bit later we noticed that conversation had drifted to talking about reverse entropy and why it was impossible to observe time going backward . . . at that point we knew it was working.

About twelve hours later my girlfriend dropped by (it was the next day) and I was jumping around the office telling everybody to look at my hooves. It wore off about four hours later. After a solid hunk of sleep I got up feeling ridiculously mentally refreshed.

I enjoy infrequent controlled use of hallucinogens, I find it a great mental recharge and also a pretty good time. I live in New York now and I was quite happy to see that San Pedros are even easier to get ahold of in the states than the were in Oz :)

<comment><USER3> If you've never done Peyote, it's a bit different, containing lots of different alkaloids. The effect is pretty similar though. Always depends on the person and context.

San Pedro is really easy to grow yourself, and totally legal.

<comment><USER2> I haven't actually eaten Peyote, that's interesting that there is a different effect. I wouldn't turn any down if I cam across it but San Pedro is so easy and cheap to come by and since it's mescaline as well I can't imagine it's too different. Thanks for the info!

</comment></comment></comment><comment><USER4> For people working in high tech, LSD usage increased creativity the following day.

<comment><USER5> I know people who took LSD innocently in the wrong environment and they're sectioned under mental health. Use with care.

<comment><USER6> Interestingly, I hear these stories all the time of "I heard of someone..." "know of someone..." "who took acid and is committed to a ward in a mental health facility." but have yet to ever have anyone verify this.

It makes the permanent "bad trip" seem almost myth (not saying you are part of this group, just brought this to mind)

<comment><USER7> More important to me; as I understand it the possibility of relapses at a much later date are not a myth. As such, I feel it's totally reasonable for law enforcement and similar jobs to immediately reject anyone with a history containing LSD (and I understand at least some do). So, if you want to work in law enforcement, you might want to avoid LSD.

(If you think LEO's should be allowed to have a history of LSD, let me ask you- assuming relapses happen- do you really want a guy with a gun and the authority to use it tripping on you? It may be million-to-one, but I sure don't)

<comment><USER6> While I believe your reasoning seems logical, it is flawed if you are singling out LSD or other "drugs". I'm not saying I do not agree with you.

But, alcohol abuse is estimated to be twice as prevalent in law enforcement (in the U.S. at least) than in the general population.

Alcohol Dementia is caused by long-term or excessive drinking (I don't believe it's long-term drinking, instead long-term unmoderated (excessive) drinking) that causes serious cognitive problems--in fact, 10% of all dementia patients reportedly have a history of prolonged alcohol abuse.

And if you know about dementia / alcohol dementia, that is just as scary a thought, and a much more imminent and likely danger compared to someone "relapsing" from prior LSD use.

Just food for thought.

And, mind you, a person can have a "flash-back" regardless of drug use if it was traumatic--e.g. post-war.

<comment><USER7> I wasn't singling out LSD. If dementia can cause similar effects, it makes just as much sense to prevent people with a history of any dementia, or something that will reliably cause dementia, from becoming LEO's.

</comment></comment></comment></comment></comment></comment><comment><USER8> Studies have shown that ibogaine treatment reduces craving for opiates, stimulants (like cocaine or methamphetamine) and even alcohol after a single dose. What is especially intriguing to scientists is the fact that this effect can last a long time (anywhere from ten days to a few months), allowing the person to experience a state of mind they may not have anticipated experiencing again. Please visit <http://www.ibogaine-treatment.com> for more information.

</comment><comment><USER9> On a related note, here's a mathematician comparing his experiences with DMT and LSD: <http://www.youtube.com/watch?v=AYDgmpiE-U0>

</comment><comment><USER10> There's also peyote use in the Native American Church.

</comment><comment><USER11> I wonder if I could link LSD to the jerky movement of a very clever professor I know...

</comment><comment><USER5> To paraphrase one of the people in the video LSD is like a catalyst: it depends on who you are and where you are.

Against all the benefits that these drugs offer they can also create mental illness. These drugs definitely need some control as they have just enough power to ruin as to enlighten. It would be good to advocate personal choice but widespread use can cause problems with society.

<comment><USER3> _they can also create mental illness._

I'm sorry but this is a a claim frequently made without context. Some evidence would be refreshing, along with some known causation, neurochemical or otherwise.

An anecdotal example, a friend of mine developed severe depression brought on by something inhibiting serotonin production/reception. Since LSD can vastly increase serotonin temporarily he suspected frequent LSD use could have something to do with it. This is one case out of hundreds of cases I know with no negative consequences. Going by my personal experience psychedelics are less dangerous than alcohol.

But personal experience is inadequate to explain the effects of these substances.

<comment><USER12> There have been hundreds of documented cases tryptamines causing psychosis and HPPD. If you want evidence just go to Erowid. Or read the book Darkness Shining Wild. Even at the MAPS conference last week there was a talk by a guy who developed severe psychosis after doing LSD. He thought he was the reincarnated Jesus and stayed awake for four days straight writing a new holy book, and then camped outside a bookstore for a couple months passing out copies to everyone who walked by. And then when he finally realized what he was doing a couple months later he tried to kill himself. The talk should be online in 6 weeks or so.

edit: Check out this YouTube video about a guy developing psychosis--

[http://www.youtube.com/watch?v=F7HBCSF9nfs&playnext_from...](http://www.youtube.com/watch?v=F7HBCSF9nfs&playnext_from=TL&videos=f7rDYcdB_w4)

Also, listen to Ben Fold's song Not The Same, about his friend who did LSD at a party and was never the same again: [http://www.google.com/url?q=http://popup.lala.com/popup/5046...](http://www.google.com/url?q=http://popup.lala.com/popup/504684672132202214&ei=QnjcS4zLHY_StgP065ioBg&sa=X&oi=music_play_track&resnum=1&ct=result&cd=2&ved=0CAkQ0wQoADAA&usg=AFQjCNGllK10UeWm4KbX0tF_f1SJHuttqQ)</comment></comment></comment>


Fun With C# and HP Laserjets | Programmer XR - <AUTHOR> http://p-xr.com/fun-with-c-and-hp-laserjets/ <comment><USER2> This is a very old technique. I came across it six or so years ago: the article where I found the code, <http://odetocode.com/humor/68.aspx>, is from 2003.

It's a lot of fun though. And PJL can be very interesting to work with: I built a tool that used it to query printers for status information (although the amount of information I could extract seemed very dependent on the printer).

<comment><AUTHOR> Yes its old, but the fun is just as much :-) Seems like a nice tool, but i guess printers use alot of SNMP nowadays</comment></comment>


FlyByChat = IRC + Web 2.0. Feedback appreciated. - <AUTHOR> http://beta.flybychat.com/#join=hackernews

<comment><USER2> Mibbit: I don't have to create an account Meebo: I just have to log in with my existing accounts (then there's also meebo rooms)

Also, the fact that the title flashes about new messages when I've just opened the tab and there are new things in the default chats is annoying. I didn't choose to receive the messages, after all.

</comment><comment><USER3> Seems like a decent idea, but showing up to the site, I didn't really understand what the point of the site was. The hn title made sense, but the site doesn't seem to explain that well; nor does it explain to me why I should use it instead of IRC. (It also never finished "loading", I assume that's just a js error though).

<comment><AUTHOR> Thank you. Re: IRC, the answer is that I'm trying to address a different market. IRC is great for us nerds. But there's no good mass consumer version at the moment, and that's what I'm going for.

<comment><USER2> Questioner: Why should I use this instead of IRC

The answer?: _I'm trying to address a different market_

Something doesn't quite fit....

<comment><USER4> read the answer as "You wouldnt"

It looks like he is trying to make a chat application for the people who dont have the inclination to figure out irc, therefore people who already use irc have no reason to switch.

</comment></comment></comment></comment><comment><USER5> Does it use IRC on the backend? This is a nice UI, being able to set it up with a custom IRC server would be very nice.

Another cool feature would be the ability to embed a chat window on another website.

<comment><AUTHOR> No, it's not actually IRC, just web-based chatrooms. That comparison has caused some unnecessary confusion. Embeddable is coming soon.

The problem with making a web-based interface to IRC is that you're liable to get blocked like Mibbit.

<comment><USER6> Why not a web client, to an IRC gateway, to _your own_ IRC servers, though? That would be my strategy—scaling an IRCd is a very, _very_ well-researched problem, compared to scaling your own proprietary backend.

<comment><USER2> I've always thought that IRC should be more of the technology, not the tools.

More importantly, being able to use IRC would offer the easy solution to the critical mass problem.

</comment></comment></comment></comment><comment><USER2> The big challenge you have isn't appealing to a different market than traditional IRC. That one is the easy problem to solve.

The hard bit is getting critical mass. Without enough people logged on and chatting, no one new would stay logged in and chatting. As it's only text based, there's none of the voyerism that chatroulette offered in return for sticking with it.

<comment><AUTHOR> I completely agree that the hard bit is getting critical mass. I don't think video is necessary: there's already a proven demand for text-based chat, which is much larger than ChatRoulette's.

</comment></comment><comment><USER7> I really like it and can appreciate the technical aspect but I was really hoping for a web enabled IRC client that didn't require me to connect over port 6667.

I would use a web enabled IRC client every day. Crap, maybe you just gave me an idea for my next project.

<comment><USER8> <http://www.mibbit.com/> does this.

But when I last tried it I couldn't get onto Freenode and my guess is that their IPs are blocked on a lot of networks.

<comment><USER7> Yeah, Freenode isn't listed. I guess a service like this could allow spammers to have a field day.

</comment></comment></comment><comment><USER9> I like that it suggests rooms to create based on your Facebook interests. Creepy, but awesome.

</comment><comment><USER10> It'd be nice if it supported OpenID.</comment>


Linux 5.6 is the most exciting kernel in years - <AUTHOR> https://www.phoronix.com/scan.php?page=article&item=linux-56-features&num=1 <comment><USER2> It's great to see all these new features entering the kernel. Here are a couple of other things I've seen in recent changelogs:

\- The 5.4 kernel can use CIFS as a root filesystem, meaning CIFS can replace NFS for diskless boot.

\- The 5.3 and 5.4 kernels both include prep for merging PREEMPT_RT into mainline. This will be a fantastic addition that benefits embedded Linux nerds like me.

<comment><USER3> For more info on the second point: [https://en.wikipedia.org/wiki/Linux_kernel#Preemption](https://en.wikipedia.org/wiki/Linux_kernel#Preemption) seems to have something to do with real-time operating systems, but I didn't dive into it.

Edit: Thanks for the downvotes without commenting what I should do differently next time?

<comment><USER4> It aims to turn Linux into a real-time OS. The preempty patchset aims to give faster response times but the main focus is to remove all unbounded latencies - for example, situations where the delay can vary depending on other factors.

<comment><USER5> This would kill most use cases for QNX+POSIX.

<comment><USER6> You'll still need QNX if you want to run a full GUI Unix-like OS from a _single_ floppy disk.

<comment><USER7> Recent QNX has removed Photon and encourages the use of Qt instead which while can be made small, certainly does not fit in 1.44mb especially in 64bit

<comment><USER8> Yeah, the usual size for a minimal Qt with either QWidgets or Qt Quick / QML is about 15 MB.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I'm really excited about the NFS client cache stuff.

It's crazy that the whole system grinds to a near halt if it loses connection to the NFS server, from an end user perspective.

I look forward to some time in the future when Debian incorporates this kernel. I prefer to use stock kernels. I used to enjoy messing with my distros, but these days I prefer stability.

<comment><USER10> I'm not an NFS expert, and I've often wondered about client caching of NFS to improve performance. Does this exist at all currently?

<comment><USER11> NFS has had caching modes since the beginning. Or at least as long as I have been using it. It's behavior can be controlled by using async or sync options.

NFSv4 is actually quite nice. Anything earlier should be avoided.

<comment><USER10> Could you elaborate on why it's nice? I only ask because the OpenBSD maintainer, Theo de Raadt, seems to believe, quite strongly, the opposite: [http://openbsd-archive.7691.n7.nabble.com/nfsv4-td18690.html](http://openbsd- archive.7691.n7.nabble.com/nfsv4-td18690.html)

I don't understand NFS well enough to know what to believe.

<comment><USER12> I've seen that thread before but just read it through in its entirety. All I got from it was "OpenBSD people are assholes, and not in the Torvalds 'constructive asshole' way, just in the 'being an asshole for the sake of being an asshole' way".

<comment><USER13> There is few strong words here and there, but nothing more injurious than what you would hear by staying in a school for 5 minutes. Once you understand the liking of such words by their writers, it's easy to mentally replace them by more politically correct version if it bother you. Moreover, they just critize tech, not people and that's an important distinction imo.

<comment><USER14> Sorry. No. There's no "political correctness" at here

Theo's comments in particular seem to start at

"NFSv4 is a gigantic joke on everyone."

This isn't politically incorrect, it's just noise. Nothing is gained from this comment. Even Linus with his infamous "rants" would have actual commentary laced in, Theo is just being dismissive

After someone reaffirms that they would like to use it, he replies

"Hahahahaha. That's a good one."

"I guess by "all the other protocols" you must be rejecting all the rest of your network traffic as "not protocols" or "not services"."

Again. Not helpful, just noise

<comment><USER15> Well, to be fair there was at least one poster who suggested that OP use SFTP instead of NFS... I mean why bother with a vegetable peeler when you could use a chisel instead?

So yeah, like you said--absolutely no useful information was conveyed in that thread. Besides any lurking bystanders learning those "in the group" are complete assholes.

[http://openbsd- archive.7691.n7.nabble.com/nfsv4-tp18690p1871...](http://openbsd- archive.7691.n7.nabble.com/nfsv4-tp18690p18719.html)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> i don't really understand this: "The AMD k10temp driver finally starts reporting voltage/current for Zen CPUs and numerous thermal reporting improvements. This is a big step forward thanks to the community but unfortunate these Zen/Zen2 thermal/power reporting bits have taken so long and there are still some mysteries that remain."

why wouldn't AMD set aside a couple of engineers (or at least one) to make sure their processors are supported here? it's not like this would be a huge drain on their manpower resources and the company itself should have an immense interest in the best possible linux support.

<comment><USER17> Zen CPUs are notoriously broken on Linux and AMD doesn't seem to care. If you ever try to install Linux on a first-get Ryzen box and want an uptime longer than 3 days, you'll want to keep this handy:

[https://github.com/qrwteyrutiyoup/ryzen- stabilizator](https://github.com/qrwteyrutiyoup/ryzen-stabilizator)

<comment><USER18> You have to disable a key security feature (ASLR) to have a stable AMD-based linux system??

That should have been treated as an all-hands-on-deck emergency by AMD.

<comment><USER17> In my case I only had to use the "Power Supply Idle Control" workaround. Apparently some BIOSes have a setting for this but mine doesn't.

</comment></comment></comment></comment><comment><USER19> For some more information on the various features in this release, check out the 5.6-rc1 LWN[1] article. As usual, that article only covers the first week of the merge window (Corbet is probably writing the second part as we speak).

[1]: [https://lwn.net/SubscriberLink/810780/ae4429af6a4ba40d/](https://lwn.net/SubscriberLink/810780/ae4429af6a4ba40d/)

<comment><USER20> Why are you posting a SubscriberLink to an LWN article to HN? That's not really the point of the links. They're for sharing in small groups not for giving away paid content to thousands of people.

<comment><USER21> LWN are happy to see them posted: [https://news.ycombinator.com/item?id=1966033](https://news.ycombinator.com/item?id=1966033)

</comment></comment></comment><comment><USER22> There are a number of new io_uring opcodes appearing with 5.6 as well: fallocate, openat, close, statx, fadvise, madvise, openat2, non-vectored read/write and send/recv.

</comment><comment><USER23> > _Year 2038 work beginning to wrap-up for 32-bit systems_

I wonder how many of these vulnerable systems will be upgraded to kernel 5.6?

<comment><USER24> ... I'm struggling to think there was ever a reason to store epoch seconds as signed.

Was there a use case for "we need to pretend to have 65 years worth of system time before 1970?

<comment><USER25> From a favourite Reddit thread:

\- Why in the hell would a date value-- particularly one that's an offset-- be signed?

\- - How were you planning on indicating dates prior to 1970-01-01?

\- - - What date before 1970? We just all assume those do not exist.

\- - - - "Now you've made me feel old." "How old are you?" "Let me put it this way: when I was born, time didn't exist."

[https://old.reddit.com/r/programming/comments/2b4kpg/conspir...](https://old.reddit.com/r/programming/comments/2b4kpg/conspiracy_and_an_offbyone_error/cj2p2dk/)

The full context is ... kind of fun:

[https://old.reddit.com/r/programming/comments/2b4kpg/conspir...](https://old.reddit.com/r/programming/comments/2b4kpg/conspiracy_and_an_offbyone_error/cj1z7x1/?context=3)

<comment><USER26> Well if we bite the bullet and use a 512 bit unsigned int we can represent time zero as the Big Bang and we should be good until the heat death of the universe, based on my napkin math. But I'm no physicist or kernel contributor so unsure of the implications.

<comment><USER27> What happens when we revise the moment of the Big Bang? Maybe need signed 1024 bit just in case.

<comment><USER26> Might as well just make it signed at that point. We'll never need more than kilibit to represent time.

</comment></comment></comment></comment></comment></comment><comment><USER28> Drooling over that picture of a dozen AMD EPYCs. Those processors are seriously awesome. The newest sr.ht server, tenshi.sr.ht, was provisioned to run git.sr.ht and has an EPYC 7402 24-core @ 3.35 GHz at its heart. It can compile the Linux kernel x86_64 defconfig from scratch on an NVMe in under 30 seconds. Our main build server is also EPYC, a 7281.

<comment><USER29> I usually don't mind some on-topic advertising, but this is a little too bold for my taste.

<comment><USER30> This is not some large corporate-driven, heavily marketed project. It is _real_ , community FLOSS.

</comment></comment></comment><comment><USER31> Any indication whether this make it into Ubuntu 20.04?

<comment><USER32> any reason for choosing ubuntu over arch for personal computers? Or any rolling release distro for that matter

<comment><USER33> Ubuntu takes all of about 10 minutes to install a full blown desktop and Just Works™ based on my recent experience. Not to take anything away from the amazing tweakability and customizability of Arch, but the target audience is completely different.

<comment><USER32> I use the anarchy distro to help me through the installation. It doesn't change the fact you need to understand the underlying installation process, but reduces the installation time to several minutes. There is also arco linux for a more user-friendly interface

</comment></comment></comment></comment><comment><USER34> It's interesting to see how adding of features correlates with the quality of a software. I haven't had problems with wifi on Linux since 2012 (when I came back to it from OS X after leaving 2006 with huge problems before NetworkManager was introduced, etc.). It was until two or three months ago after a kernel update my laptop started dropping the connection with my 5 Ghz network, only at home. It seems to be a common problem with the Qualcom chip driver which worked nice on this laptop for almost two years.

I like progressiveness a lot and also new features, etc. and I found a workaround (switched off 5Ghz at home), so it's ok and I can always install an older kernel too which is the freedom of free software, I wasn't able to do stuff like that on OS X.

<comment><USER35> Ah! I should try this!

Arch on a dell xps, fine for two years and now have some issue where network buffer doesn't flush (cursory investigation). Have been fairly sure it's an issue post update. Thanks for the idea :)

<comment><USER34> Yeah mine is a XPS 13 with Arch on it.

</comment></comment></comment><comment><USER36> Looking forward to multipath TCP.

Anyone tried it out yet, how does it look so far?

<comment><USER37> Looks good to me, but the Google guys are trying very hard to move the web over to UDP based HTTP/3 instead of MPTCP.

</comment></comment><comment><USER38> Wireguard!! Woot!

I'll be putting this kernel on all production systems, without testing, on Sunday night while everyone is off.

<comment><USER39> What product are you launching tomorrow morning?

<comment><USER40> It's a new blockchain-based analytics database which uses SOAP as the wire protocol.

<comment><USER41> IPO/ICO. Now.

</comment></comment></comment></comment><comment><USER42> > Intel MPX support is completely removed.

A bit sad about this one, Intel should talk to Oracle, ARM and Cambridge Computer Laboratory on how to implement this kind of feature properly.

</comment><comment><USER43> The Year 2038 stuff is cool. Do we have projections for how much unpatched stuff might still be around in 2038 to cause issues? The benefit of getting the fixes merged 18 years ahead of time is so those fixes proliferate, but I have to imagine there's a nonzero amount that won't/can't upgrade... Curious if there's any idea of how big an issue this could be, even if we solved everything today.

</comment><comment> gjsman-1000 Rc1 was released just 30 minutes ago! I'm compiling away!

</comment><comment><USER44> There's certainly a lot in there!

However, there's not much that is of interest to me. Given that, plus the mammoth amount of changes in the kernel, I think that I'll be delaying updating to this kernel for a good, long time. Just in case.

</comment><comment><USER45> crap there's a USB4 already?

</comment><comment><USER46> Already compiling... :)

</comment><comment><USER47> I've rolled back to 4.19 as 5.x kernels works very bad on my setup. Any IO makes system unresponsive. Box is i7, integrated video, ram 32Gb, SSD 512Gb running debian testing. run "apt update" and mouse stops, music skips. 4.19 runs flawless under any reasonable load on this system.

<comment><USER48> What options do you see in /proc/cmdline when you are on 5.x?

<comment><USER48> And could you add the output of 'lspci -vv' perhaps on pastebin

</comment></comment></comment><comment><USER49> This sounds like a lot of impressive work. I wonder if there would be any benefit to the Linux kernel adopting more of agile release cycle. This waterfall like release surely has to increase the risk surface.

Perhaps the mindset of web software and operating system kernels don't overlap enough for this to be reasonable?

<comment><USER49> Not sure why getting downvoted. Is this an ignorant question? Or maybe just not fans of the word agile? Oh well. Guess I'll just have to ask someone who contributes the the kernel in person the next time I meet one.

<comment><USER50> It's a pretty ignorant question; it could also be taken as flamebait trying to start up an agile vs waterfall argument.

New stable kernel branches are released every 2-3 months after weekly release candidates, with bugfix releases in between new stable branches and a new LTS branch every year or so. If you want anything "more agile" than that for OS kernel development, then you're probably prioritizing agile dogma over the realities of trying to not break the most fundamental component of the operating system.

<comment><USER51> Agile is juatvas much about small features as time. Imo this kernel comes with too many changes; smaller steps miggt be preferable.

<comment><USER50> It sounds like you're just not accustomed to paying attention to a project with such broad scope. Most of these changes have fairly narrow impact on just a single driver or subsystem. It would be silly to say "we're going to postpone release of this new GPU driver because we have too many new network drivers in this release", because there's no reason to expect such a policy to actually improve the quality of kernel releases, and it would obviously be detrimental to the pace of feature additions.

Actual far-reaching systemic changes are a pretty small portion of this and most other stable kernel releases.</comment></comment></comment></comment></comment>


Carmen Ortiz's Husband Defending Her Prosecution of Aaron Swartz - <AUTHOR> https://twitter.com/tomjdolan

<comment><AUTHOR> Tom Dolan is an executive at IBM, and husband of US Federal Attorney Carmen Ortiz.

Copying the tweets here in case he deletes them:

Tom Dolan @tomjdolan @mkapor Truly incredible that in their own son's obit they blame others for his death and make no mention of the 6-month offer.

Tom Dolan @tomjdolan @dangillmor Ah, not really. That article says he was offered a 6-month deal. 6 months is not 35 years or a lifetime.

Tom Dolan @tomjdolan @thinkprogress Completely false. Aaron Swartz was offered a plea deal of 6 months. 6 months is not 35 years.

</comment><comment><USER2> Article on Boston.com with the screenshot of Dolan tweeter posts

[http://thehill.com/blogs/hillicon- valley/technology/277353-l...](http://thehill.com/blogs/hillicon- valley/technology/277353-lawmakers-blast-trumped-up-doj-prosecution-of- internet-activist)

</comment><comment><USER3> "Offering" a 6 month deal after threatening a 35 year sentence isn't an offer, it's intimidation.

<comment><USER2> Can't agree more. Pleading guilty for 6 month for Aaron would have meant publicly admitting that he was nothing but a common thief without a day in court. Despite what Dolan says in his twitter, the threat of 35 years must have been pretty real in order for DOJ to use it as leverage against Aaron.</comment></comment>


The Moral Dichotomy of US Politics - <AUTHOR> https://medium.com/viewpoint-weekly/the-moral-dichotomy-of-us-politics-b1c33ca7a066 <comment><USER2> In my experience, is usually the ones proclaiming moral superiority that have the most to hide (or are the most willfully blind).

There is no moral dichotomy between reps and dems, they are pretty much equally depraved from what I can tell.</comment>


Show HN: A Risk-like game where bugs grow their hives - <AUTHOR> http://growhive.io/ <comment><AUTHOR> Some tech info:

\- Built with ReactJS using a modded version of Ali's awesome starter kit: [https://github.com/alicoding/react-webpack- babel](https://github.com/alicoding/react-webpack-babel)

\- Backend is FireBase (I may have to change this as cost could be a huge issue)

\- All randomization uses the probability-distributions library (double plug!) which I built to have a JS package with the same syntax as R (go R!).

\- Icons for avatars built use the fantastic IcoMoon service: [https://icomoon.io](https://icomoon.io)

<comment><USER2> Why do cells I own randomly empty?

<comment><AUTHOR> There's a built in decay factor (current half-life approx 4hrs/cell). That keeps the entire board from filling up and preventing new users from coming in.</comment></comment></comment>


Ask HN: Has anyone implemented a zero-maintenance system? - <AUTHOR>

I am more and more interested in designing and developing a zero-maintenance system - i.e. a system that once built requires no maintenance whatsoever.<p>Is this possible to achieve at all? <comment><USER2> It is an interesting question, but it would help to be a bit more crisp. You need to define 'maintenance'. Allow me to explain.

A sun-dial, requires little maintenance after it has been set up. Cleaning off the bird feces and the leaves is all. It is not "zero" maintenance though. A trail duck is just a pile of rocks, and in the absence of getting knocked over requires no maintenance, but may require repair from time to time. A spacecraft on a mission to Pluto might require a software change or a course correction, but its hardware is not changed once it launches. A humming bird feeder sits on my porch and provides sugar water to birds in the neighborhood, when it runs out I pour in more.

So there are three things people often lump under the general heading of maintenance:

Repair - making something work after breaking.

Resupply - replacing consumable supplies, cleaning, and adjusting

Renew - giving something new capabilities or changing its operation by replacing parts or software

If you're being pedantic about the term, there is no such thing as 'zero maintenance' if you want a system to remain stable. Entropy is a thing.

So perhaps the more crisp question is, are people working on systems with really low maintenance requirements? Where "low" can be defined as hours of maintenance vs hours of operation or skill level of maintainers vs skill level of the builders, etc. Sure there are some really famous ones like the clock of the Long Now. Every museum in the world with interactive exhibits tries to design systems that will run with very little maintenance for a long time. Pretty much every operations lead spends time working on ways to keep large numbers of computer systems running with little human intervention.

</comment><comment><USER3> This was the default way software worked before widespread use of the internet, and in particular game software up until the last few years. You buy a game on a CD or cartridge, and that's it. There is no "maintenance" after that.

Before internet use was common, there was just no really convenient way to deploy bug fixes, at least to consumers. Enterprise software updates were probably handled by a visiting rep who applied the updates, or a set of tapes with instructions to the local administrators.

But for consumer/office stuff, when you shipped something, that is what it was. You worked pretty hard to be sure did what it was supposed to do.

<comment><USER4> You still had plenty of bugs, of course. Users just had to deal with them longer - until the next upgrade, which usually wasn't free.

</comment></comment><comment><USER5> This question should include a time frame. (just like when someone desires a "real time system", the deadline is key to answering the question "is it real time or not"

One way to set this time frame could be "life of the system" \-- which might be say 2 years, or 5 years, or 50 years.

The more constrained your requirements and design are in terms of inputs and outputs and error states, the more you can validate and get closer to maintenance free (finite state machines are a nice pattern for this).

Many embedded systems (appliances, space program gear) achieve this, but I've noticed that as those are built more and more with off the shelf general purpose hardware and software they become more error prone and require maintenance (due to competition and time to market tradeoffs?)

edit: one final thing re error states : watchdog timers. These can be tremendously useful in reducing maintenance, and keeping functionality alive. When certain error states are entered, the watchdog timer triggers and the system can restart to a known good state and, hopefully, restore its core functionality until that particular error state is entered again.

<comment><AUTHOR> Thanks for the comment. You are right. I did not think of all the space exploration equipment that is up there. But maybe there are doing upgrades as well? I don't know.

Also I like what you said about timeframe. Why software doesn't have a warranty period after which the software is absolute?

<comment><USER5> certainly they are doing upgrades and maintenance. They have probably set time frame requirements for these too, for instance, "device must be able to function with current sw for N hours/days/months while out of radio contact"

Your question was a great one though -- and worthy of pursuit as a sw engineering goal in general!

</comment></comment></comment><comment><USER6> Of course it's possible, but I don't know where you're trying to go with this.

Set a lifespan the product should be able to operate without maintenance, based on your goals and engineering constraints. Design with the lifespan in mind, perform lifecycle testing. Then release your product, stop working on it and don't offer support.

The feasibility of such depends on what you're trying to build. Customers have different expectations of lifespan, maintenance needs, and manufacture support depending on the product. A garden hoe is not an alarm clock radio, which is not a car, which is not a general purpose operating system.

The status quo of maintenance for any product domain is an inherent limitation to putting out something better. You can't just jump ahead of the competition because you will it so. You need some combination of: building with higher quality components, insight into the problem domain that none of the current commercial solutions have, or simply more productive (ie. more expensive) R&D.

If you're just looking at products that currently require maintenance and are licking your lips at the idea of selling a turn-key solution, join the party. Otherwise roll up your sleeves and make low maintenance a key design goal of your product.

</comment><comment><USER7> Sure I've seen it it did not run anything modern os wise. The MS DOS based control computer at my dads previous work place had an uptime of what was close to forever. We are talking stability in the range of ten to fifteen years. It ran a climate computer system control program and the control software newer crashed. Because MS DOS it was single tasked and the control program was very stable.

At the time there was little computer hacking activity so you did not have to update the software either. Backups was done to floppy disks and there was a reserve hotswap backup computer. For remote control you would dial into the computer via modem, first via 300/1200 baud that is 1200 bits per second. Then later at lightning 9600 baud.

I'm also sure you find very good old engineering in the computers of Voyager.

<comment><USER8> People do maintenance all the time on spacecraft, including sending commands to get stuck things unstuck, updating firmware, and other things:

[https://books.google.com/books?id=le-M5s191moC&pg=PA126&lpg=...](https://books.google.com/books?id=le-M5s191moC&pg=PA126&lpg=PA126&dq=telstar+repair+radiation+damage&source=bl&ots=nWVQAv2qIW&sig=t9nRqSJnQS9mRYOihilc6KrBvaU&hl=en&sa=X&ved=0CEsQ6AEwBmoVChMIs76ItIboxgIVxveACh3XnADR#v=onepage&q=telstar%20repair%20radiation%20damage&f=false)

</comment></comment><comment><USER9> It is always something to aim for but with anything time always catches up. I would say if it is anything internet or connectivity wise externally in any form comm wise, then you have to plan for maintenance from a security and protocol changes aspect over time (thinking transaction data formats).

So if security not an issue or removed from the project via some wrapper be that system locked in a room with control and other layers. Then you still have to plan for how long it is meant to last and being realistic.

WIth most business assets your talking 5 year write off at best tech wise with many 3 or maybe less, depending upon use.

SO possible - in the right situation - yes. But do not forget security.

THough remember time always a factor and also wear and tear and with that a pen eventually runs out of ink and required refiling. So dependant upon the timeframe doable but for many at what cost.

Another aspect would be look at what you have got that has fulfilled this criteria and not required maintenance and then ask, were you lucky or did you plan it that way as for many it usually ends up as some legacy system, hardly anybody uses or with low usage that has no internet connectivity at all. That is when you see your Amiga or C64 or early PC working away without issue.

But things fail and however well you plan things, things happen and to not at least check everything working and monitoring because it was designed to just work is something you should also plan. Expect the unexpected.

</comment><comment><USER10> Your question provoked an interesting thought process when I began to answer it.

I had first thought that one of my projects was zero-maintenance as I truly gave it zero-maintenance in the three years between when I built it, and when I sold it. It was a website which indexed content from others. I had coded the "spider" in such a way that it was quite flexible if the content on the page changed a bit and it stood me well for those three years. I had a database back up system in place that backed up to another server.

But then I began to realise that although I had gave the site zero- maintenance, it wasn't truly zero maintenance. If I'd had a hardware failure, I'd have a backup of the database but no way to automatically spin up a new server and put it in place. But even if I had some monitoring in place for that, what if the monitoring service went down? I guess what I'm getting it as that there can never be a zero-maintenance self-sufficient service - just one that is incredibly well automated by great engineers.

</comment><comment><USER11> My fridge is 30 years old and unless you count periodic cleaning and defrosting as maintenance it has had no maintenance at all in that period. One of my two freezers is 25 years old, ditto. Microwave oven is over twenty as well, but as the internal light has failed I suppose it doesn't quite count. My wife's hair dryer wasn't new when we met and that was forty years ago, still going strong.

I very much doubt that anything I buy from now on will last so well, mostly because of quite unnecessary use of electronic control systems that add unnecessary features and extra failure modes. Of course my new fridge uses only half as much power as the old one which means that the new one saves me about 125kWhr per year, which in turn means that it will take about twenty years to pay off the investment, good job that wasn't the reason I bought it.

As someone already pointed out you have to specify the expected life time to be able to evaluate 'zero-maintenance-ness' of a system.

</comment><comment><USER12> The idea of zero maintenance is appealing but out of reach in a lot of ways. I suppose you mean some kind of software system. From the perspective of the systems world the runtime dependencies are a moving target. Most platforms evolve and their interfaces change over time.

The teams the develop these platforms (Java/Node.js/Ruby) have to balance support for old code branches with the development of new ones. Once the platform team leaves a code branch behind, the problems start to multiply. Zero day exploits are developed for zero day vulnerabilities. The underlying operating systems also evolve and leave the old versions of the platform behind as well.

At some point you have to open your applications code base back up and update it for the updated platforms. If you don't the application dies with its platform. Sort of like the ship that sinks of rust or building that collapses due to the accumulation of deferred maintenance.

</comment><comment><USER13> Many non-networked systems neither need nor support updates.

If your system is networked, there is always the risk of security updates being required. This can be minimised by extreme effort, but if you have to support SSL/TLS? At least you need a way of deprecating the vulnerable ciphersuites.

Would you want a web browser with zero updates? It would gradually become a handicap.

For consumer equipment, "zero maintenance" means "disposable": in the event of trouble, throw it away and buy a new one. Good for manufacturer turnover, not so good for the environment.

The other option is simply 100% outsourced maintenance, which has long been an option. Some mainframes would even do their own fault reporting, all you'd have to do is say hi to the technician and let him into the building.

</comment><comment><AUTHOR> I think I should have been a bit more clear but I also like that the question was a bit vague because there is a lot of interesting comments highlighting things I never thought about it.

I believe that software engineers failed in some ways because we always factor the maintenance as part of the development cost. In other words, we assume that we have to maintain a system once it is built. It is even more relevant with web applications which give the impression that they are in a constant flux. I don't buy the idea that web apps needs to adopt because standards don't move that fast and almost all browser are backwards compatible with sites that were developed in the 80s. I don't know what is behind HN but its simplistic, non-fluid interface hasn't been changed (I don't know actually) since it was made which for me shows that it is possible to make something useful without the need to constantly change. There are many example like that.

I also like the analogy that some of you wrote about physical systems. Indeed, there are physical systems that hasn't been changed for years and they still work. There is also a lot of software systems, mainly SCADA stuff, that are also designed never to be changed. Not long ago I heard a story about a pentest on a SCADA system that was controlling a dam. Despite that the pentest found a bunch of vulnerabilities, it was not possible to change the system because its author was dead long ago. The dam operated just fine even with the vulnerabilities in its software.

Another point I wanted to bing about is about defining time and version constrains. Back in the days software was not continues. In other words you get Doom 1. Doom 2 is a different story. Therefore, Doom 1 source code can go free. I would say that Doom was very much low to zero maintenance system, albeit a software one. Bugs were part of the character of the software. Hacking the software through its bugs was as close as it get to magic in the digital world. As we get more connected we require to maintain the software.

These are just a few things that came to my mind. I will add more thoughts as I go over your comments.

<comment><USER8> For operational software that runs a business you are going to need to change the software because the business changes.

It is true that the visual UI of HN looks stable but behind the scenes they are always making changes to improve the community. Part of it is dealing with attacks & spam, part of it is trying to shape the behavior of users who are in the grey area between positive and negative contribution.

So far as security, that is another force for perpetual change.

</comment></comment><comment><USER14> If it's doing anything useful, then no. The definition of 'useful' will change over time, so what the system is doing will fall away from that unless it is changed to bring it in line with the new requirements. Cue maintenance.

The trick isn't eliminating maintenance, but in making maintenance as hassle- free as possible. The best way I've found to do this, the way I do it personally, is to build enough slack into the human system surrounding the automated system (in other words, the business you're working for) to adequately design, implement and iterate maintenance procedures. "Ship" the procedures by handing them off to an unskilled person so you can get feedback for iteration.

</comment><comment><USER15> I don't think there is such a thing.

Best case scenario is a lot of automation and monitoring.

Where I work our dev / engineering team is investigating machine learning to automate repair a bit better. For example, over a 7 day period we record data for load on our backend and that ML model predicts and generates autoscaling rules according to historical data. Some of our services are about as low maintenance as I would think they can get (autoscaling, autoremoving poorly performing instances, etc) but I'd like to improve and only make an engineer get involved when the system can't be trusted to make the right call.

</comment><comment><USER16> If the requirements are static and you don't require external connectivity, it's very possible.

My wife is a financial person. Her billing system (it's a public utility) until 2009 ran on an AS/400 with 33mhz processor. It was probably rolled out in 1991 or 1992 and upgraded to support IP connectivity in the late 90s.

It's only connectivity was a modem that called IBM when something broke.

I made fun of her about it, but It actually worked great. The only reason it was replaced was that IBM ran out of spare parts for the printer.

</comment><comment><USER17> Google Search Appliance was supposed to be "deploy and forget" (at least in its earliest version) but it still had a connection (over phone line, IIRC) so that Google support could reach it in case of need.

Such a design makes sense only if the work the system has to do is predictably static though. Even in the case of Google Search Appliance, the moment your company adds a document in a new format the device will require some kind of external intervention to keep working.

</comment><comment><USER18> A Zero-maintenance system ? This is just what NASA is trying to build.

It's just a matter of relation of cost versus maintenance work.

If you want to build a zero-maintenance system by yourself, just try to imagine your service and servers will be launched over to Pluto or a comet, and will never come back.

But remember that you have zero-maintenance if you pay someone to do the maintenance in your place. That's what people generally do when paying for cloud services.

</comment><comment><USER19> I have a server that doesn't do anything at all. It has neither inputs nor outputs connected to it, and isn't even connected to a power source.

Except that I suppose I'll still have to blow the dust out of it every so often, and make sure it's in an environment where it won't rust.

(To be less glib: what do you mean by "system"? What do you mean by "maintenance"?)

</comment><comment><USER20> My hair dryer has been working for 20 years without any maintenance. However I don't think that would be a good idea for anything connected to the internet. However, if it's a closed system, and it does the same thing constantly in a constant environment, I think it's possible.

<comment><AUTHOR> But what if anything you program is written exactly like that. The internet is still based around 20-30 years old protocols and there are software systems out there that still work. So what is the secret sauce of building a software system that will survive without any maintenance for the next 20 years?

</comment></comment><comment><USER21> Any system is zero maintenance as long as you choose not to maintain it.

Also, zero is a very small number.

</comment><comment><USER22> Most hardware is like this, right? Your microwave does not (yet) get firmware updates.. what ships has to work right.

I don't think this is a good idea for a web server.. browsers change, you have to do some things to keep current..

</comment><comment><USER23> AFAIK the only zero-maintenance system is no system.

So in a way, every time I realize I don't need to build a "system" for a given task, I am building "a zero-maintenance system" of sorts.

</comment><comment><USER24> I have a couple "quick fix" excel based solutions that still run, with no maintenance 7 years later. There is nothing more permanent than the temporary.

</comment><comment><USER25> It depends on what you mean, what your goals are, what you are trying to build, etc.

"No maintenance whatsoever?" I doubt it. Things break, get old, go obsolete, are insecure, and wear out.

Perhaps, you should worry about "nines of uptime" or "fixed requirements" or something along those lines.

Simplicity is first. The more complex, the more maintenance. "Everything Should Be Made as Simple as Possible, But Not Simpler" \- [http://quoteinvestigator.com/2011/05/13/einstein- simple/](http://quoteinvestigator.com/2011/05/13/einstein-simple/)

"No moving parts."

Make it highly available and redundant. Power, cooling, networking, hardware, and software redundancies are needed.

Make it immutable. Change and mutable state will create maintenance. Implement functional programming, if you write software.

Monitor it and make it self-restart. Somebody already mentioned watchdogs, for hardware.

Make it ultra secure. No outside networking?

Program finite state machines....

If you imply a "hardware and software" solution, these points sound like you need redundant hardware and Erlang/OTP. Take a peek at OTP and the Erlang- based languages (Erlang, Elixir, Joxa, and LFE).

At least with redundant power, cooling, hardware, and Erlang/OTP (Elixir/OTP, etc.,) you gain the ability to do all of these things.

With Erlang/OTP, you can achieve very high uptimes, and if you design it correctly, you do have the ability to hot-patch running code, if you do have to (rarely) perform maintenance.

While you're at it, you also get distributed programming, concurrency, and parallelism, for free, with Erlang/OTP. This, in and of itself, can "reduce maintenance."

See [https://pragprog.com/articles/erlang](https://pragprog.com/articles/erlang) and [http://stackoverflow.com/questions/8426897/erlangs-99-999999...](http://stackoverflow.com/questions/8426897/erlangs-99-9999999-nine- nines-reliability)

</comment><comment><USER26> You should probably define "maintenance", otherwise it's very difficult to agree on such a system.

<comment><AUTHOR> Once built - you don't have to attend it anymore.

<comment><USER27> You need to be more specific. In the face of what kind of disruptions will it continue? For example:

* do you need to keep supplying electricity?

* do you need to keep paying the bills so that someone else will supply electricity?

* will it continue working if there is a hardware failure? What kind of hardware failures can be tolerated? Do you need to intervene if the data gets migrated to a new system?

* will it continue working if there is a flaw (not just a bug) found in something? e.g. it uses TLS version X which turns out to have some flaw in Y years time

* what about it society changes in some way so that the load on it is quite different in the future?

* how long are you expecting to do zero maintenance? At some point the operating system you run on will be obsolete, and there will be no upstream fixes to critical security bugs - what will happen then?

<comment><AUTHOR> I should have been more clear but you have some excellent points that make me thinking. I think the crucial elements are to define the timeframe and usefulness which is somehow related to time.

</comment></comment></comment></comment><comment><USER28> This seems analogous to a perpetual-motion machine.

</comment><comment><USER29> Define maintenance.

Are you talking about software?

</comment><comment><USER30> Back when I was a systems engineer, I built a couple of systems that come as close as I'm ever likely to see to zero-maintenance.

One of them is a piece of automation that looks for Active Directory accounts that are "inactive" based on a variety of criteria (including correlation with data not stored in AD). If they're considered "inactive", then they're disabled and their description is updated to indicate when they were disabled and why.

I originally wrote it as a 6-12 month stopgap until it was replaced by a fancy commercial account lifecycle product. I believe it's now 7 years later and it's still in use by the team I used to be on when I wrote it.

This may sound like a relatively simple task, but it actually wasn't, which is why (IMO) almost no one ever succeeds in building low/zero-maintenance systems. Some of the challenges I ran into:

\- Some users only use their accounts in ways that don't update the last logon timestamp in Active Directory. I can't remember all of the specifics offhand, but one was that at the time, there were still BlackBerry users, and if they only ever used their AD account for email, and only read email on their BlackBerry, the timestamp wouldn't be updated, so the automation had to query the BES database to look at their last usage their too and use the most recent of that vs. AD. I think there were 3-4 things like this, and the automation used the most recent of them all.

\- Employees go on maternity and military leave, and disabling/deleting their account would make for them being really unhappy when they got back. So the automation also has to check the HR system to see if their record is flagged as being on some sort of extended leave.

\- The government requirement that spurred the development of the automation only applies to accounts for people. There are plenty of service accounts that log on infrequently enough that they would be disabled, so the automation also has to differentiate between those accounts and accounts that represent people.

In addition to the basic functionality, I also felt that it had to have significant safety features in place, because if something goes wrong and _all_ accounts get disabled, then no one can log on to fix the problem. Among some of the other safety features:

\- With each iteration, the automation calculates how many accounts will be disabled during the next iteration as well. If that number exceeds one threshold, warning emails are sent to the account administration team. If it exceeds a larger threshold, it will refuse to operate altogether.

\- If no information was obtained from one of the data sources that it uses (e.g. a database was moved to a different server and the connection string wasn't updated in the account automation config), it will refuse to operate and generate warning emails.

\- I don't remember the details, but there are special conditions for things like "too much time elapsed between iterations" and "the last iteration took place after the current iteration" to catch edge cases where there are problems with time synchronization.

I was able to build the automation in a way that made maintenance as close to zero as possible. In the ~7 years it's been running, AFAIK the only thing that's needed to be changed were the thresholds for number of accounts disabled in a single iteration, because the company expanded its use of AD and suddenly it became normal to operate against a thousand or more accounts at once instead of e.g. 200. A database connection string might have been updated when a DB got moved to another server as well.

Anyway, trying to predict all of the things that can go wrong even for such a simple system turned out to be a _lot_ of work. My experience is that it gets dramatically worse as the system itself becomes more complicated (e.g. complicated enough to be a commercial product as opposed to an engineering maintenance task). I don't think it's really practical to do it with significantly more complex systems - modern computing involves too many changing variables.

For an analogy, consider trying to build a zero-maintenance system that waters and fertilizes a garden in a way that keeps the plants healthy. It wouldn't be _that_ hard to build one that would handle the current garden. Imagine trying to build one that would handle literally any plant that someone could put in the garden. It's not _impossible_ , but you'd need all kinds of wacky sensors and logic to figure out what each plant was and how frequently to water/fertilize it. It's much easier and less error-prone to just require that the gardener update a table that lists what types of plant are in which part of the grid, and _maybe_ generate an alert if something changes that indicates that the table may no longer be up to date.

</comment><comment><USER31> The iPhone is pretty close, unless you physically damage it

Not sure what is meant by "system" here.

<comment><USER32> The battery has a lifespan and eventually needs replacing as well. Not sure if that falls within the scope of physical damage, its subjective I guess. Even routine charging could count as maintenance. What about cleaning the screen (to get fingerprints off the screen)? Surely that counts as maintenance too? New wifi & cell protocols could be invented that also render it obsolete. If you run out of space on it, old files aren't automatically pruned... going through my photos deleting stuff counts as maintenance I'd say. I've also had it become frozen / sluggish and had to reboot (even with iPhone 6)

</comment></comment><comment><USER33> Yes. Or at least that is the goal.

What type of "system" is it? A database.

I got fed up having to do maintenance on my database, specifically worrying about having to expand its storage capacity. I'd constantly be woken up in the middle of the night because my entire web application had crashed because it ran out of disk space, because the database greedily pre-allocated excess space to improve performance. I'm not a DevOps guy, so figuring out LVM and MDADM on the fly was a nightmare. And as my app got more popular, things got worse and I just could not keep up.

But then I sat back and thought about it for a minute. I was deploying my app in the cloud, not on my own physical machines. Why was I worrying about expanding storage capacity when the cloud can sell me more of it than I could possibly keep up with? Why was I maintaining finite space when there was an infinite amount available? That doesn't make sense.

The other problem was that despite the fact everything else was working (the web server, the frontend javascript, etc.), if the database server was down then nothing would function properly because data is the life blood of my app. This sucks, if one piece breaks the whole thing is defunct.

So after a while, I decided to change all this. I decided to build a database that would be zero-maintenance, it hit the top of hackernews several times, some big name investors (Tim Draper) got behind it. Check out this demo of it automatically recovering from the complete loss of primaries - [https://medium.com/@marknadal/gun-0-2-0-pre-release-auto- rec...](https://medium.com/@marknadal/gun-0-2-0-pre-release-auto-recovery-of- primary-fault-5f4ffbe63301) .

So how is it zero maintenance? Well some other people in this thread mentioned some important points:

\- There are fewer moving parts - there is no database server. Instead it gets embedded into your app server and your frontend (see next point), so the only thing you have to maintain is your app. If your app is flawless or (more likely) can auto-restart just fine, then you'll won't need to do any maintenance.

\- It is highly available and redundant because it uses Peer-to-Peer architecture, like BitTorrent. So even if your server crashes, your app can continue to work in offline mode or with WebRTC (not implemented yet) continue to interact with other users. When the server auto-restarts at some point, the offline data will sync back up and resolve any conflicts. If you have more than one server running, then things will continue to work even if one or many of them crash.

\- Immutable data allows the system to recover and resolve conflicts without your manual intervention. I'll let others talk about how awesome immutable data is, I'm sure you've heard enough about how many problems it helps with. Especially when it comes to maintaining systems, stuff can't get corrupted, and even when it does, the immutable data allows it to reconstruct itself.

\- State machines allow the system in advance to know what is valid and invalid behavior, so it for the most part can avoid going down paths that are "incorrect" which lead to having to do manual maintenance, because it is already instructed in the first place what states to avoid or how to exit those states if it gets into them.

I'm super glad you asked your question, because I feel like a lot of software developers out there are super negative and bitter about it because most systems they have worked with have basically ruined their lives (like what happened to me, having to fix stuff in the middle of the night). But just because a lot of things have been like this, doesn't mean we can't borrow from engineers or mathematicians ways to make zero-maintenance systems. So I really hope you find what you are looking for or build one yourself, if you do please let me know email@example.com because I'm interested in that sort of stuff. Maybe we could start some group/forum around zero-maintenance systems!

</comment><comment><USER34> Yes, I have. It failed. No one used it, so it didn't require maintenance.

I assume that that's not what you're looking for, though.

There's a fine line between "maintenance" and "improvement", and without the latter, you have stagnation. There certainly are systems that require very low levels of maintenance. I have a friend who built a program in Erlang that is still running, 10 years later. (I don't mean that _the code_ is still in production. I mean that _the program itself_ is still running.) Of course, Erlang allows the definition of "a program" to span multiple machines, and we're debating terminology here...

Pay-as-you-go maintenance is best. Don't allow technical debt if you can help it, push back against The Business on deadlines, certainly don't allow that micromanagement under the name of "Scrum" to get in or else you're just fucked when it comes to quality because you'll get a fuck-quality-I-need-to-complete- story-points culture, and create a culture of doing things right the first time.

Not that you'll necessarily use them, but learn a few things about strong statically typed languages like Haskell or Ocaml (Java doesn't count; that's shitty static typing). One of the great things about Haskell is that it allows safe refactoring. You're not holding your breath every time you change the code, because the compiler will usually tell you where your change broke things, and you can just go in a fix them. It is possible to write highly reliable software in dynamically typed languages (such as Erlang, mentioned above) and I don't mean to denigrate those tools at all, but it's a bit harder, especially when you're fairly new to programming, to do so.

Finally, once your system reaches a certain size, you will need tests no matter how good your type system is. They start to become an obvious win around a thousand lines of code. Consider generative testing (e.g. QuickCheck) rather than hand-written tests if you can.</comment>


MIT EECS Department Reconstructed to EE, CS and AI - <AUTHOR> http://news.mit.edu/2019/restructuring-mit-department-electrical-engineering-computer-science-1205 <comment><AUTHOR> The reorganizational plan: [https://www.eecs.mit.edu/news- events/announcements/eecs-reor...](https://www.eecs.mit.edu/news- events/announcements/eecs-reorganization-plan)</comment>


How to write a resume that will make it through recruiter's screening systems - <AUTHOR> http://blog.predikt.co/how-to-write-a-resume-that-will-make-it-through-recruiters-screening-systems/

<comment><USER2> Better to just avoid dealing with recruiters altogether.

Except for secretive financial shops (if that's your thing) and temporary contracting gigs, they're almost never needed or useful.

Nearly all the good FT jobs are advertised publicly (and loudly). So just apply directly.</comment>


Blockchain or Government - <AUTHOR> https://medium.com/@andrewmoroz/blockchain-or-government-8c655b920650 <comment><AUTHOR> Blockchain will dramatically weaken governmental power by (1) providing competing contract enforcement mechanisms and thus reducing the need for government; and (2) making most transactions anonymous.</comment>


Show HN: SpreadServe  – Cloud automation for Excel spreadsheets - <AUTHOR> http://spreadserve.com/ <comment><AUTHOR> Hi, long time trading systems hacker and originator of SpreadServe [1] here with some background: I was inspired to build it after finding myself in a meeting in a London Investment Bank in 2014 hearing a manager say "the traders have defined the accrual calcs in a spreadsheet, now we just need a couple of C# devs for a few months to build a real server to do the calcs". I realised I'd seen that pattern repeat time and again over the ten years I'd spent working on London trading floors. By hacking together Excel Addins in C++ myself I'd enabled an options trader to build a program trading system in Excel by plugging his pricing sheets into Liffe's ETO limit order books. I put an exotics trader on Bloomberg by connecting his huge 30 tab sheet to my etrading gateways, then gradually replaced the spreadsheet with C++ pricing servers. My own XLL Addin was running on hundreds of trading desktops, and I'd helped any number of traders lash together ad hoc pricing and risk spreadsheets with XLLs connecting them to market data, prices and quotes [2]. The same cycle kept repeating: trader whips up spreadsheet, sheet becomes business critical, trader tires of manual keying of data, hitting F9, and the flakiness of huge Excel sheets and demands the dev team replace the sheet with a scalable service. Then the dev team takes months to replicate the spreadsheet functionality in a C++, C# or Java server, and the trader gets frustrated by lengthy change cycles.

I realised that we can escape that frustrating cycle by building a server runtime for spreadsheets. Just as node.js took JavaScript to the server side, SpreadServe is "node.xls": an asynchronous scalable server side runtime for Excel spreadsheets that supports XLLs, RTD & VBA as well as a REST API, RDBMS integration and websockets subscribers. As Felienne says [3] "spreadsheets are code". But that code is trapped in a desktop IDE for grid based visual functional programming: Excel! And that's not the right environment for reliable automated operation. So SpreadServe's aim is to separate the development and rumtime environments for calc heavy spreadsheets: Excel for rapid change cycles by tech savvy power users like traders, then SpreadServe for production scalability, resilience and audit logging.

[1] [http://spreadserve.com](http://spreadserve.com)

[2] [http://babbingtonslade.com/industries/](http://babbingtonslade.com/industries/)

[3] [https://etrading.wordpress.com/2015/08/13/spreadsheets- are-c...](https://etrading.wordpress.com/2015/08/13/spreadsheets-are-code/)

<comment><USER2> I had a summer job in 1997 at a large Insurers (kill me), and people on my team would spend at least half an hour a day waiting for networked, dependent Excel files to calculate after opening them.

Since then, I have always suspected it was still a problem in large financial institutions, although the few times I mentioned it to people they looked at me blankly. Now I feel vindicated!

Out of interest, does the Financial Industry use any analogues to source control and unit testing for spreadsheets?

<comment><USER3> I wrote a blog post about unit testing Excel workbooks using Python's built-in unittest module: [https://www.zoomeranalytics.com/blog/unittests-for- microsoft...](https://www.zoomeranalytics.com/blog/unittests-for-microsoft- excel)

</comment></comment></comment><comment><USER4> I did several Excel to App implementation for the reasons you mention and more.

I'd like to better understand the architecture of your proposal to consider it for my future projects. Does it run real Excel instance under the hood? Or is there a full emulation/interception going on?

Can you cope with several linked excel spreadsheets at the same time ? Can you handle custom DLL loading/extending? Or perhaps, are you willing to share a whitepaper/architectural outline?

<comment><AUTHOR> I'm using the Open Office Calc engine under the hood for Excel formula emulation. I extend that with my own implementation of the Excel4 API's xlcall32.dll, so that XLLs can invoke the Excel4 API. I also emulate Excel's built in RTD client, so that XLLs that supply an RTD server can push real time data into a sheet. Feel free to download the install kit [1], or email me on email@example.com for more detailed discussion. Thanks for the interest!

[1] [http://spreadserve.com/s3/downloads.html](http://spreadserve.com/s3/downloads.html)

</comment></comment><comment><USER5> Knowing John's work at various investment banks, I would venture to guess that Spreadserve will be a top-notch product. Scaling Excel is something that has been needed for a long time. How many times have we, in IT, gotten complaints from traders and quants about Excel crashing with a large number of calcs?

</comment><comment><USER6> How does it compare with HPC Services for Excel? [https://msdn.microsoft.com/en- us/library/ff877824(v=ws.10).a...](https://msdn.microsoft.com/en- us/library/ff877824\(v=ws.10\).aspx)

<comment><AUTHOR> HPC requires you to refactor your spreadsheets to distribute the workload across the nodes. XLL C++ code needs to be tweaked to make them parallelizable. And the resulting ensemble still needs to be driven from a desktop Excel. SpreadServe takes unmodified spreadsheets and runs them on a server, completely automated and decoupled from any GUI.

</comment></comment><comment><USER7> Really nice work! As someone who has automated several spreadsheets by essentially reimplementing them in a "proper" language like C# or Python for several financial institutions, I see the immediate need for a product like this across all business units. Not only does your product help save time and resources, but your focus on proper testing can easily help reduce very costly errors (which happen more often than one would like to think).

One question, how does your product integrate with 3rd party APIs like Bloomberg or SNL?

<comment><AUTHOR> Thanks! SpreadServe has 3 APIs: REST/websockets, C++ and Python. A SpreadServe deployment is a cluster of servers. So if you wanted to push Bloomberg market data into a spreadsheet you'd code a new server component in C++ and/or Python against the BBG API.

</comment></comment><comment><USER8> What is the licensing model? Completely open source, free for small time use with license fees for heavier use, charge for all commercial use, undecided yet?

I ask out of interest rather than because I am thinking of licensing it. I can see it will be highly useful though to those that need it.

<comment><AUTHOR> Free for public instances of SpreadServe that phone home spreadsheet details to spreadserve.com's live page [1]. Chargeable for offline instances that don't phone home as they have a paid license key. Some of the codebase is OSS [2]. More details on the license model here [3].

[1] [http://spreadserve.com/cws/cdashboard.html](http://spreadserve.com/cws/cdashboard.html)

[2] [https://github.com/SpreadServe/SSAddin](https://github.com/SpreadServe/SSAddin)

[3] [http://spreadserve.readthedocs.io/en/latest/license.html](http://spreadserve.readthedocs.io/en/latest/license.html)

<comment><USER8> Thanks. Making the add-in open source makes sense from a business perspective, lets people inspect the code they are running on their machine.

</comment></comment></comment><comment><USER9> I worked and help launch something similar a couple years ago : [http://calcfusion.com/](http://calcfusion.com/) .

</comment><comment><USER10> This is really good.

What is your sales plan?

<comment><AUTHOR> Free public licensed [1] SpreadServe deploys phone home to publish spreadsheet info on the spreadserve.com live page [2]. That's the way I aim to build adoption. Offline license keys are chargeable, and stop SpreadServe phoning home. Small hedge funds and asset mgrs are my first target market for paid license keys. I'm not going after big banks early as the enterprise sales cycle is so lengthy and torturous is can kill small vendors. I've seen that first hand, so those customers are for much later.

[1] [http://spreadserve.readthedocs.io/en/latest/license.html](http://spreadserve.readthedocs.io/en/latest/license.html)

[2] [http://spreadserve.com/cws/cdashboard.html](http://spreadserve.com/cws/cdashboard.html)</comment></comment>


D&D on Microsoft Surface multi-touch table - <AUTHOR> http://www.boingboing.net/2009/10/29/dd-on-multi-touch-ta.html <comment><USER2> I don't like it. The best part of D&D is the ability to ad-lib. Every attempt I've seen to make the interaction through technology reduces this ability (with, perhaps, the exception of simple chat rooms).

</comment><comment><USER3> This is probably going to give away what I spent a large portion of my youth doing, but that is the most compelling application I have so far seen for the multi-touch table.</comment>