New military automated airdrops will use image recognition instead of GPS - <AUTHOR> https://thestack.com/cloud/2016/01/19/new-military-automated-airdrops-will-use-image-recognition-instead-of-gps/ <comment><USER2> From the article: "The current implementation of JPADS relies on GPS tracking to guide unmanned drops to the correct coordinates, but any deviation from the drop target, which can be caused by wind or other environment factors, can result in the necessity for troops to venture into frontline territory to retrieve the delivery."

The image shows a parachute drop. I'm not sure how image recognition will help reduce the impact of wind or other environment factors. It seems like military GPS now in the sub-meter accuracy would be - by far - the best guidance system. Anyone have any insight as to how image recognition is better than GPS or even helps (although article implies replacement)?

<comment><USER3> 1) GPS is a weak signal and can be jammed or spoofed.

2) Your satellite imagery might not be accurately aligned to the coordinated system. If you want to land on a little flat spot, then doing it visually will work even with misaligned imagery.

<comment><USER4> I'm sure the NRO can source some really accurate satellite and drone based terrain imagery if needed.

<comment><USER5> Maybe, but the cost in that infrastructure is the bureaucracy of getting that data to the machine doing the dropping. There is a huge walled fortress surrounding imagery acquisition and analysis that would make tunneling that information to the airplane/drone in a timely manner very hard in its current form.

</comment></comment></comment></comment><comment><USER6> "which is aimed at reducing the 3000 casualties which in 2007 resulted from inexact air-drops in militarily sensitive environments such as Afghanistan."

Is that saying 3000 casualties _just in_ 2007? That number is a lot higher than I would have expected it to be. I didn't realize this was such a problem.

<comment><USER7> Another part of the problem was using the same colour packaging for food-aid air drops and cluster munitions. About 10% of cluster bomblets don't explode.

[https://www.hrw.org/legacy/backgrounder/arms/cluster- bck1031...](https://www.hrw.org/legacy/backgrounder/arms/cluster-bck1031.htm)

[http://www.landmineclearance.org/page2.html](http://www.landmineclearance.org/page2.html)

[http://www.rawa.org/cluster2.htm](http://www.rawa.org/cluster2.htm)

<comment><USER5> Yeah, not only that, but they look like big soda cans. If there's one thing little kids have eyes for, there it is.

</comment></comment></comment><comment><USER8> Reminds me of TERCOM's predecessor, DSMAC - [https://en.wikipedia.org/wiki/TERCOM#DSMAC](https://en.wikipedia.org/wiki/TERCOM#DSMAC)

<comment><USER4> Yeah, totally thinking of missile terminal guidance.

I guess fear of jamming, capture, and the need to keep system costs low is why they're not going for a mapping radar approach instead as that would get them all-weather capabilities.

<comment><USER9> In addition, a passive system is useful for covert as well as overt drops. An active system isn't.

</comment></comment></comment><comment><USER10> Better link that describes the other concerns about GPS that were brought up and describes in more detail how the system works: [http://www.defenseone.com/technology/2016/01/army-testing- ro...](http://www.defenseone.com/technology/2016/01/army-testing-robo- parachutes-dont-need-gps/125151/)

<comment><USER11> > The testing of a GPS-free version of JPADS is yet another example of efforts > to develop alternatives to satellite guidance. "GPS is very expensive to > launch and operate," Defense Secretary Ash Carter said during an April 24 > podcast from Silicon Valley, according to National Defense magazine. The > global positioning system, he said, "makes us vulnerable to attacks, it is > impossible to use in the valleys of Afghanistan or in a big city [where > signals are blocked], or in places where the signal is poor." "At DoD, we > worry about enemies jamming GPS signals." Army Maj. Christopher Brown, who > helps run the service's efforts in position, navigation and timing, or PNT, > told C4ISR & Networks last year. "Threats to military GPS have evolved and > improved at a rapid pace — from a proliferation of small-scale commercial > jamming devices that can readily be purchased on eBay to large-scale > military anti-access/area-denial (A2/AD) capabilities."

So the real benefits here are: works in mountains, and future-proofs against better GPS jamming.

<comment><USER12> Iran managed to "hack" GPS to steer a state of the art American drone to land safely at a location of their choice over four years ago.

[https://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incid...](https://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incident)

I would say that GPS's vulnerability is a current problem rather than a future one.

</comment></comment></comment><comment><USER13> Time to bring back camouflage cities[1] and ghost armies[2] then. [1] [http://www.lockheedmartin.com/us/100years/stories/camouflage...](http://www.lockheedmartin.com/us/100years/stories/camouflage.html) [2] [https://en.wikipedia.org/wiki/Ghost_Army](https://en.wikipedia.org/wiki/Ghost_Army)

<comment><USER13> My bad; now I know what an air drop is, and it doesn't involve blowing anything up. Still, the above links are fascinating.

<comment><USER14> But Ghost, uh, Terrain can still make it possible to steal airdrop supplies by confusing the camera en route to its destination.

</comment></comment></comment><comment><USER15> I've some of the self-driving systems are relying on remembered images of highways as much as lidar or radar. A memory of roads near your residence and workplace is useful.

</comment><comment><USER16> This might save lives in Modern Warfare's Drop Zone mode.</comment>


A Note About Sabeer Bhatia's Interview in Founders at Work - <AUTHOR> http://www.foundersatwork.com/1/post/2009/02/a-note-about-sabeer-bhatias-interview.html <comment><USER2> Googling down Internet memory lane for HoTMaiL. Hallucinogenic optimism. Great phrase.

> Jurvetson remembers: "He brought in these revenue estimates showing that he > was going to grow the company faster than any in history. We dismissed the > projections outright, but he insisted, 'You don't believe we're going to do > that?' He had _hallucinogenic_ _optimism_. He had an unquenchable sense of > destiny. But he was right. He grew the subscriber base faster than any > company in the history of the world."

Wired 6.12 "HotMale" December 1998

[http://www.wired.com/wired/archive/6.12/hotmale.html?pg=2...](http://www.wired.com/wired/archive/6.12/hotmale.html?pg=2&topic=&topic_set=)

</comment><comment><USER3> Why is this needed? JL just interviewed people, and they subjectively stated their opinions, however true or false. I would think the burden of independently verifying every claim (esp regarding fuzzy details of what people _said_ in private) would be too great.

<comment><USER4> For the same reason any journalist wants to be told the truth, to know when they are not told the truth, and to call people out when it happens. As a proxy for absolute truth, good journalism requires complete reportage even years after publication. Rep and goodwill are your most valuable assets.

I don't know JL well but I imagine that she would not do this over of a simple he said / she said disagreement. On the other hand I don't think this deserves to be front-page news -- she is only making sure she has the record straight.

</comment></comment><comment><USER5> Slightly OT here, but F@W is one of my all-time favorites. I found it very inspiring and informative.

I remember reading somewhere that Jessica Livingston might be working on a sequel. Does anyone know if there's any truth to this?

<comment><USER6> I believe she announced she was working on a sequel during the talk she gave at the 2008 Business of Software conference.

</comment></comment><comment><USER7> I found Sabeer Bhatia's interview one of the less useful ones in the book, though it was still worth reading. He sounded too negative about VCs, became a Google fanboy for no reason multiple times during the conversation, and gave too much importance to the notion of the 'killer idea'. Compare this to (say) Mitch Kapor's interview, and you see two completely different personalities, only one of which I would enjoy working with.

<comment><USER8> I really liked the fact that there were some seriously different people interviewed. For instance, the Excite guy, fresh out of college, compared with the RIM guy, who chose between the Blackberry and some project for the space shuttle. And yet they both got rich out of their respective startups. I liked seeing that variety.

</comment></comment><comment><USER4> Has he responded to this? Are there any more errata in F@W?

<comment><AUTHOR> Sabeer approved the interview before publication, but after the book was published he asked me to remove those parts if there was a second edition. He didn't say specifically that the things he said were false, just that they hurt people's feelings. (Many people in the book cut stuff out of their interviews, but usually because the material was controversial or confidential, not false.) But once I got evidence that what he said was actually false, it seemed appropriate to post a statement about it immediately.

None of the other things people said in interviews were false that I'm aware of.

</comment></comment><comment><USER9> Five words: Passwords in the browser cache

<comment><USER9> To be more concise: When using Hotmail in 1997 on a college machine, I found that the cache contained people's Hotmail passwords. That's not a sign of genius.

<comment><USER10> If you're able to make 400 million bucks with that, it definitely is! (a business genius, at least - which by itself is a lot, no?)</comment></comment></comment>


This Map Shows the Largest Employer in Every State - <AUTHOR> http://didyouknowfacts.com/map-shows-largest-employer-every-state/ <comment><AUTHOR> Wow, besides the obvious (Walmart), health care is _huge_ business here in the States.</comment>


Ask HN: For multiprocess/multithreaded tasks, what is the best language now? - <AUTHOR> Hey all. I'm working on an application for a client and we've come to a scenario where there's a large number of items to process every hour. Each item involves a separate http request. As I was discussing this I was wondering what the best language for parallel task processing is now. Where best would be a decent trade-off between code readability and performance (if such a trade-off were required). Thoughts? <comment><USER2> How large a number of items?

How does your preferred language fair when processing at that rate?

Does the risk of developers developing in an unfamiliar language outweigh the cost of adding hardware to support a familiar solution?

</comment><comment><USER3> elixir/erlang should be a good fit.</comment>


Uber gets into car rentals and public transit – TechCrunch - <AUTHOR> https://techcrunch.com/2018/04/11/uber-gets-into-car-rentals-and-public-transit/ <comment><AUTHOR> If Uber was smart, they would buy masabi and put their sales team to selling every transit agency. They could own the market for mobile ticketing.</comment>


Cringely: Is Google on Crack? - <AUTHOR> http://www.pbs.org/cringely/pulpit/2007/pulpit_20070727_002573.html

<comment><USER2> Summary: Google should bow down to the big telcos and not spend 2.86% to 6.22% of their market cap to open up a gigantic market because there's a danger that Google will hurt the telcos' feelings and cause the big telcos to no longer do special deals with Google.

Google is entrenched enough that they aren't going to wither and die just because they don't get preferential placement on the default landing page for the cell phone's browser. If Cringely is saying that the telcos would actually _block_ Google, that would be an indicator of much bigger problems with the telco cartel.

Sounds like it's Cringely who needs to put down the crack pipe.

<comment><USER3> Many suggest Google's mobile plans exceed the cell phone's browser however, which is why the carrier control issue really is of importance to them. I agree with the article in this regard. Several respectable analysts believe a Google phone is ~6-12 months from being unveiled, and that Google has interests in more advanced on-deck applications such as context sensitive searching (based on location, time, etc). Both of these objectives are definitely "blockable" by the telcos under current conditions.

<comment><USER4> isn't the iphone a google phone? i thought SJ and ES were on each other's boards. google is trying to create the platform and capitalise on the traffic (by betting it can build better products) - that's their business space. apple makes consumer devices which use traffic. sounds like a pretty solid proposition to me.

<comment><USER5> I think that if Google does have a phone in the works, it will be a no-frills, inexpensive phone that will cost a lot less than the iphone. That way, google won't compete with the high end of the market that iphone has covered.

</comment></comment></comment></comment><comment><AUTHOR> I don't agree with this article's conclusions, incidentally. I doubt there's much the telcos can do to Google, no matter how vengeful they feel. But the article helped me understand what this controversy is about.

<comment><USER3> I also dont think the demands set by google were a brash mistake like this article suggests.

The general public is becoming more aware that the carrier's chokehold on them is stunting innovation and choice. The iPhone is a perfect example. When the iPhone was released, groves of people with existing contracts signed the 2yr AT&T contract anyway, but not without a feeling of bitterness. Everyone wants the Apple iPhone, not an AT&T phone. Everything AT&T about it is a downright annoyance.

Statements like the one made by Google over the spectrum restrictions reach the ears of the public. Google is saying: "We will stop the telcos from raping you over the coals if the FCC will accept our rules to help you, the end user, by giving you freedom of choice". I think now, more than ever before, people are standing up and demanding action like this. Google is shown as "good cop" who will help fight back the oppression that the telcos have imposed.

Regardless of the outcome of the 700Mhz auction, the carrier's restrictions will crumble, its just a matter of time. Just like Ma Bell and so many other examples in history, you can only hold back innovation and competition for so long. By making their stance known, Google is positioning themselves as the company who will be active to do things right, just like they have done in the internet space.

The issue at hand though is the importance of this spectrum in particular... Yes there are talks of utilizing the "white space" spectrums to get every inch out of available wireless freqencies (which Google is also interested in), but 700Mhz is the real meat. It is a BIG deal. Not only is it the last "prime real estate" that will likely come available in a long time, it is a lower frequency than the other wireless phone bands and therefore propagates better. Google owning this spectrum is far more important than internet search, and I know they realize it. I just hope they put their money where their mouth is because like the article suggests, now they have stirred up the bee hive by pissing off the carriers.

</comment></comment><comment><USER6> I think Cringely makes some valid points about the risks Google is taking but I think he is being overly paranoid. Even if he is not and the world is run by the telcos, I still say good on Google. Even if only some of the rules Google is proposing are adopted for this new frequency band we would be looking at a new way to network. A better way. An open way.

</comment><comment><USER3> For those interested, the FCC just ruled on this decision today:

[http://www.moconews.net/entry/419-fcc-approves-open- access-w...](http://www.moconews.net/entry/419-fcc-approves-open-access- wireless-rules-spectrum-auction-will-not-requi/)

They voted in favor of "Open Access" for 1/3 of the spectrum, which is a win for Google, but they did not enforce the other rules such as open network access. Google said they wouldnt bid unless all the rules were enforced but some speculate they might anyway...

</comment><comment> patrickg-zill Only people who have had experience in dealing with telcos know how evil they are. And any company, no matter how much of an outsider they are at first, eventually becomes corrupted and also evil (see: Sprint as one example).

Google would have to specifically and repeatedly and publicly repudiate the status quo of telco behavior in order to have even a chance of avoiding the same fate, should they get into telco-like services.

</comment><comment><USER7> Google will inevitably stand up to the telephone companies. Fighting for the old TV frequencies is as good a place to start as any.

In 25 years, do you think that Google or the telephone companies will be more relevant?

<comment><USER8> The telephone companies.

Google is a stack of contracts and IP; they're made of very ephemeral stuff. The telco's have enduring physical assets. Now, some P2P wireless topology might eventually kill the telco's, but I doubt it.

<comment><USER9> They own a ton of physical infrastructure.

</comment></comment></comment><comment><USER10> Sure hope Google gets what it is asking for here. We need this kind of network. I would love to give away a phone which carries my applications on its "desktop" straight out of the box. Imagine the possibilities. Free cellular for anyone willing to purchase $200 bucks a month worth of widgets from my sponsor.

Talk to Verizon about an idea now and your sure to see your idea pooped on or stolen. An open system would let everyone have a hack, and talk about investors opening wallets for companies with ideas. Deja Vu, the internet reborn yet again....

</comment><comment><USER11> ..the author is on crack.The whole article is nothing better than a soap opera:

"Google, the "little search giant" feels like bidding. Doesnt have enough cash to win the bid. Rolls out evil plan in sheep's disguise demanding 'openness' ,so that the winning bidder will have to Open up everything.Auction day.As expected Google doesn't win the bid.The winner and gangs in retaliation blocks Google.com from the service. Google dies ."

Honestly, WFT?

</comment><comment><USER8> Cringley mentioned the precariousness of Google's position as the #1 search engine. I switched away from google to search.yahoo.com months ago. Every now and then I run queries on both and I am consistently getting better results from yahoo. I'm failing to remember the specific examples, but twice in the last week google failed to provide a relevant link on the first page at all but yahoo succeeded.

Has anyone else found that google search has degraded?</comment>


Show HN: CheerpX – x86 virtualization in browser using WebAssembly – Python Demo - <AUTHOR> https://www.leaningtech.com/pages/pythondemo.html <comment><AUTHOR> This demo requires WebAssembly tail calls support. Instructions for how to enable it in Chromium are included.

<comment><USER2> Sounds very interesting. Can Firefox be used too? I am on mobile right now and it only shows the "It looks like CheerpX could not start" in Firefox for Android.

<comment><AUTHOR> Firefox does unfortunately not currently support WebAssembly tail calls. Sadly, they also seem not be making any progress on this feature, even if it's supposed to be in the "Implementation Phase" of the WebAssembly standardization process.

</comment></comment></comment><comment><AUTHOR> Feel free do drop me any question: [https://twitter.com/alexpignotti](https://twitter.com/alexpignotti)

</comment><comment><USER3> I've seen many python repl websites. What's the difference here?

<comment><AUTHOR> This is literally running the Ubuntu x86 packages for python in the browser, by dynamically recompiling binary code to WebAssembly.

This demo is indeed just a Python REPL, but the technology is fully generic. On top of this you can make _any_ binary run. We are actually working on using this to preserve Flash content by running the official Adobe plugin safely in the sandbox.

<comment><USER4> Kind of like Emscripten but for x86 instead of LLVM?

<comment><AUTHOR> CheerpX is actually fully dynamic. You don't even need to "compile" things manually before. You can just feed binaries to the JS API and the program will run.

<comment><USER4> Appears to be proprietary based on the look of the website - what's the price range for this?

<comment><AUTHOR> Our roadmap is to release our Flash solution in 2020, and we are in the process of finalizing the pricing of that. We have not yet defined how other uses (like REPLs) will work. If you have an interesting use case for our tech, drop us a line email@example.com</comment></comment></comment></comment></comment></comment>


Amiga OS Kickstart and Workbench source coded leaked - <AUTHOR> http://commodore.ninja/amiga-os-kickstart-and-workbench-source-coded-leaked/ <comment><USER2> Devs talking about fixing bugs in narrator, the earliest TTS engine in home computers: [https://github.com/amigasource/amigaos/blob/master/v40_src/w...](https://github.com/amigasource/amigaos/blob/master/v40_src/workbench/devs/narrator/readme)

<comment><USER3> SAM (the Software Automatic Mouth) was available in 1982 for Apple, Commodore, & Atari 8-bit.

[https://en.wikipedia.org/wiki/Software_Automatic_Mouth](https://en.wikipedia.org/wiki/Software_Automatic_Mouth)

<comment><USER4> And it was developed by the same company.

SoftVoice's website still exists, but no idea if the company is still alive: [http://www.text2speech.com](http://www.text2speech.com)

</comment></comment></comment><comment><USER5> Link is Slashdotted.

Here is another link to the story: [http://www.osnews.com/story/29023/Amiga_OS_Kickstart_and_Wor...](http://www.osnews.com/story/29023/Amiga_OS_Kickstart_and_Workbench_source_coded_leaked)

Apparently the file says 3.1 but it is really 4.

<comment> white-flame Talking with people from "the scene", this is a snapshot from the 90s. It was leaked before, and now resurfaced for some reason in a more public view.

Nothing from the more recent 3.5, 3.9, and 4.x versions are in there. Those were developed by external companies long after the vintage of this leaked snapshot. There's some mention of newer versions, but they're incomplete implementations from the Commodore Amiga team, not the actual developers of the newer versions.

It also doesn't compile, isn't 100% complete, and includes a number of internal business documents, not just code & tech.

</comment></comment><comment><USER6> The timing makes it seem like it may have been an insider leak to let AmigaOS live on. Either without Hyperion's support, or with their support, only not officially and so that they have no accountability.

<comment><USER5> The AmigaOS and Kickstarter code doesn't work with PCs or Intel Macs. So there is nothing to be gained unless you have a 68K or PowerPC Amiga or one of the PowerMacs that could be hacked to run AmigaOS.

Besides there is AROS for PCs and Intel Macs: [http://aros.sourceforge.net/](http://aros.sourceforge.net/)

It is a rewrite of AmigaOS 3.1 that uses the same API calls.

The link was temporary and was deleted already.

Hyperion and Amiga had been at odds with each other over AmigaOS 4 and other things. Amiga has changed ownership many times and AmigaOS was only designed to work on Amiga computers. Had they ported it to Intel PCs it would have been a different story and been like BeOS then.

If you have a Kickstart 1.0 Floppy disk for an Amiga 1000 it has the source code on the floppy because someone grabbed the wrong disk to write the Kickstart 1.0 file to and instead of grabbing a blank disk grabbed one that had source code on it.

<comment><USER7> The Amiga world has _not_ aged gracefully. It's hopelessly fractured with something like half a dozen OS efforts all built around various philosophies of ideological purity to the old Amigas each capable of addressing markets that _might_ number in the hundreds of users.

It's kind of insane that all the various parties just haven't decided to open source everything and try to grow the community instead of taking smaller and smaller slices of a very tiny and shrinking pie. I really can't figure it out. It's just a niche hobbyist thing and charging for the software and rom images isn't ever going to make any money back for the people who put the effort in.

This is really one of the cases where I think properly open sourcing everything and just running it like a mature open source effort would be far more productive.

<comment><USER8> Someone needs to explain the whole Amiga thing to me, because I've lost the thread. When you say markets might number in the hundreds, I have a hard time believing even that. Perhaps I'm just ignorant (as I said, I've lost the thread), but why would anyone run Amiga OS any more other than for the novelty? Are there still applications that are worth spending money on?

<comment><USER7> You'd be surprised at how big the retrocomputing/retrogaming enthusiast market is. I know in the U.S. that there are _several_ shows alone that pull in north of a thousand people.

It really is mostly for the novelty/nostalgia factor. Most of the Amiga OSs run on ancient PowerPC hardware and aren't useful in a modern sense for much more than simple web browsing and IRC.

While there are certainly people who make things for the various scenes and sell them, usually they're just trying to cover manufacturing cost of physical product. Software is usually freeware/opensource. The Atari 8-bit computer scene, for example, produces lots of weird custom hardware that the makers usually sell for parts + labor + shipping, but I can't recall ever hearing of license fees for a new DOS (there are many DOSs for the old 8-bits).

What's particularly weird about the Amiga scene is how locked down the IP still is and how that seems to permeate the rest of the scene. It's like the IP owners think that somehow they'll suddenly come across hundreds of millions of dollars in VC money and will reignite the Amiga fire with new hardware and software that will sweep the world...if only they hold on to the licenses for 30 year old ROM images a _little_ bit longer. Or that they'll somehow sell enough licenses to make up for millions of dollars of development investment.

No joke, AmigaOS 4.1 is actually 30EUR _today_ \-- in almost 2016 -- and it only runs on bizarro PowerPC hardware that's built out of weird industrial control system motherboards or something and sold by yet other hopeless companies. [1][2][3]

If they sell 1,000 licenses a year, their revenue is 30,000EUR.

So I mean, Hyperion Entertainment is supposedly a company and there's probably more than one person hacking away at the OS, but there's no way they're coming close to covering costs on this. If I wasn't convinced of the earnestness of Amiga enthusiasts, I'd almost believe the entire thing is some kind of complex money laundering operation.

There's even commercial software still developed and licensed: [4][5][6][7]

and even an entire app store! [8]

I really admire the enthusiasm and passion, but I just can't figure out the money angle or what the point is.

1 - [http://www.amigaos.net/](http://www.amigaos.net/)

2 - [http://www.a-eon.com/](http://www.a-eon.com/)

3 - [http://www.acube-systems.biz/](http://www.acube-systems.biz/)

4 - [http://www.pagestream.org/](http://www.pagestream.org/)

5 - [http://www.amigaos.net/software/100/amidark- engine](http://www.amigaos.net/software/100/amidark-engine)

6 - [http://www.hollywood-mal.com/purchase.html](http://www.hollywood- mal.com/purchase.html)

7 - [http://www.codebench.co.uk/](http://www.codebench.co.uk/)

8 - [http://www.amistore.net/](http://www.amistore.net/)

<comment><USER9> _What 's particularly weird about the Amiga scene is how locked down the IP still is and how that seems to permeate the rest of the scene. It's like the IP owners think that somehow they'll suddenly come across hundreds of millions of dollars in VC money and will reignite the Amiga fire with new hardware and software that will sweep the world...if only they hold on to the licenses for 30 year old ROM images a little bit longer. Or that they'll somehow sell enough licenses to make up for millions of dollars of development investment._

What I always thought was really weird is, the community _helps_ them with this. Like, the Amiga scene for some time was about the only retro scene I know of that _self-policed_ for infringement. Regular Ami fans would take it upon themselves to scour the web for people hosting the Workbench ROMs and disks and report them, and would get very very cross about requests. It was as if they thought if they could only shut down emulation people would just start rebuying real hardware in droves just to play ancient games. You can't even practically _build_ an actual high-end Amiga anymore like you can get up and running in WinUAE with a few clicks, because the accelerator and graphics add- on hardware is all mostly rarer than gold these days.

It really is the case that there's this hardcore of really obsessive Amiga fans who're convinced they can somehow force the world to once again go Amiga. No one else is like this; there's no hardcore Risc OS fans out there waiting for the day when Acorn arises again and slays Microsoft or something.

It's bizarre.

<comment><USER10> > "It's bizarre."

I agree, but I can see two good things that came of the actions taken to protect the ROMs.

1\. A company that supports the Amiga could sell the ROMs for use in emulation.

[http://www.amigaforever.com/](http://www.amigaforever.com/)

2\. It helped to push for an open source version of the ROMs (AROS 68k).

[http://eab.abime.net/showthread.php?t=56211](http://eab.abime.net/showthread.php?t=56211)

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Mirror here: [https://github.com/amigasource/amigaos/](https://github.com/amigasource/amigaos/)

<comment><USER12> Yay! Thanks. :D

This is undoubtedly going to disappear pretty quickly though.

To anybody reading this:

The original .tar.bz2 would be the ideal source to mirror, because then the checksums match up and you know you have the copy everyone else has without verifying each file manually.

FWIW, MEGA repos let you make directories. They can be up to 50GB so you have plenty of space to upload the original file along with an unpacked copy to browse. Then we just need somewhere resilient to put the link to the latest working repo.

I can fairly easily push this onto MEGA if I can get at the .tar.bz2.

My email is in my profile if you don't want to reply here.

One question though: at [https://archive.is/2TTKO#post1058888](https://archive.is/2TTKO#post1058888) someone mentions a small but confusing date issue. Was this file released more than once?

<comment><USER11> The one linked to from that forum is still exists on Wayback Machine: [https://web.archive.org/web/20151229025031/http://home.evers...](https://web.archive.org/web/20151229025031/http://home.eversberg.eu/temp/amiga%20os%20source%20code%203.1.tar.bz2)

It has a date of 20-Aug-2013 13:35, and the download on rol.im, which is also on Wayback Machine, was identical. So perhaps the date has been modified or this is a copy of a two year old release? I did not catch the FTP server releases - which were on the CCC IP address range, I guess part of the 32C3 guest network - before they went down, so I do not know for sure.

<comment><USER12> Hah, I'm out of touch with finding software... I should've thought of that. I've done that kinda of thing before. (Incidentally, I reckon the reason Archive.org isn't globally indexable is that it would abruptly cease to exist all at once if everything out there was discoverable...)

As for the date thing, one of the Amiga threads linked here mentions that this leak is actually incredibly old and dates to 1997 or so. So... yeah, there's that.

This definitely goes in my tiny software leak collection next to NT4 and Mac OS 7 though :D

</comment></comment></comment></comment><comment><USER13> There are comments](http://eab.abime.net/showthread.php?t=80875">comments) on one of the Amiga communities most popular forums by a Olaf Barthel, a developer who modernised a more complete version of the 3.x source code. He relates that you need several different C compilers for different parts of the OS, from one that needs to run on a Sun OS to various Amiga-based compilers (Aztec/Manx).

<comment><USER12> Oh :(

Here's the quote:

> Like kamelito already said: this stuff hasn't been leaked now, it's been > leaked in the late nineties. Rumors have it that Tyschtschenko handed out > the sources to a whole bunch of people in Germany (in addition to Phase5, > which already had them) to make sure they don't get lost during the next > bankruptcy.

> These sources were all over the warez boards in 1997 or 1998.

> It's the original 3.1 sources from Commodore, they require quite an exotic > setup to compile (an obscure SunOS/Solaris based Cross-Compiler amongst > other things, IIRC), Olaf Barthel had to spend quite a few hours to make > them compile/assemble with modern tools before they could be used as the > base for OS 3.5+.

Heh.

\--

I love this one from further on in the thread:

> AmigaOS is not designed and implemented in a manner which would facilitate > testing.

\--

Also, HN (Arc) doesn't use HTML, and got completely confused by the URL.

Worth reading! [http://eab.abime.net/showthread.php?t=80875](http://eab.abime.net/showthread.php?t=80875)

</comment></comment><comment><USER14> Given that, at least back when I still used the Amiga, the community Amiga Resource Project (ARP) was free, open source, and superior in all respects to Commodore's "official" AmigaDOS, so much so that it was adopted by Commodore at one point, why would one want this?

I find it hard to believe Commodore got better at writing system software as it got worse at everything else and then went bankrupt.

<comment><USER4> ARP provided an exceedingly tiny set of additional APIs. It's not in any way a replacement for AmigaOS. AROS is closer, but while it's vastly superior in some aspects (not least: it runs on pretty much every modern platform you might care about in some form or other - either native, or hosted under Linux or other), it's also still not a complete replacement in others.

</comment></comment><comment><USER15> Finally...</comment>


Ericsson pulls out of Mobile World Congress over fears of coronavirus - <AUTHOR> https://www.axios.com/ericsson-pulls-out-of-mobile-world-congress-amid-virus-concerns-5845b19a-d1d3-48a3-a164-27539c7c6277.html <comment><AUTHOR> Embedded World is also that week. Anyone reconsidering going to either?</comment>


Ask HN: How do you do on-site SEO (with meta elements) for your React apps - <AUTHOR> I've been building React web apps for a brief while now. After seeing 2 of my pages rank on a Google search result page, I realised, somewhat belatedly that all my pages would have the same title, meta description, meta keywords, Open Graph and Twitter meta elements in the HTML header unless I had a way to change them on a case-by-case basis. What is the most straightforward way for me to handle this? <comment><USER2> You need react-helmet. If you're using nextjs, you can use next-seo.</comment>


So You Wanna Go On-Prem - <AUTHOR> http://blog.lusis.org/blog/2016/05/15/so-you-wanna-go-onprem-do-ya/ <comment><USER2> I honestly thought this was satire for the first half of the article. When did working on SaaS products exempt people from understanding how to deliver software? Should we just remove the first [S] from SaaS?

I see this attitude a _ton_ in conversations with startups. A founder describes their whiz-bang thing, a question comes up about how this works in larger environments, usually followed by a mumbled reply about virtual appliances. Virtual appliances (and to some extent, docker containers) are not the solution, for so many reason, I might run out of space in the comment field listing them. The short version: OS updates, security updates, networking issues, customer-side diagnostics, size, and support for the customer's specific virtualization platform. Docker is great if your customers all use docker and you have the update process sorted out, but that is probably a small fraction of your total market.

In other words, build actual installable software that runs on some set of supported operating systems. Make a DEB, an RPM, maybe an MSI. Build an installer. Have a nifty splash screen. Add desktop links. Don't lose revenue because you can't be bothered to figure out omnibus, nullsoft, or bitrock.

If you are building software, keep in mind that customer environments are insane and should be treated as hostile. Every bit of your software and packaging needs to be paranoid, defensive, and respond well to failures. When something goes wrong, customers are not your QA team (you have one, right?). Don't make them run a thousand commands for you. Build actual diagnostic features into the product. Some organizations (hint: they have lots of money), don't let your icky code talk to the internet. Offline activation, offline updates, and offline diagnostics are super important to counting these folks as customers.

<comment><USER3> The problem with maintaining the install is that it really slows down your deployment of feature and evolving the ecosystem. It's not just a matter of extra know how. SaaS is more than just ease of use, it's a very very rapid and competive delivery of new features day in day out. Companies are adopting SaaS not just because they don't want to maintain the infrastructure / install software. They're adopting SaaS because they want the latest and greatest so they can compete better against their colleagues that don't have the latest and greatest.

<comment><USER4> Vendors have responded to this challenge for a while with Long-Term Support builds to complement the standard product cycle. Get a major set of features that your on-prem customers want, freeze the features, and keep 12, 18, 24 months between major feature updates.

Most companies of any complexity are going to be unable to integrate into their business processes all of your latest and greatest features as fast as the fictional SaaS dev team can release them (then revise, then revise again).

For most of these businesses (just read, most businesses), your software will be less of a time suck if it has a moderate release cycle with a predictable, well-advertised lead out to new changes, allowing IT departments to evangelize and pre-educate on the new capabilities.

<comment><USER5> Yes, that model works, but it is going to use up resources that simply will not be an issue if you're running entirely as a service.

<comment><USER6> You just have to charge enough to make it worth it.

<comment><USER5> I guess so, but the whole point here is that there are a lot of hidden costs you might not have considered if you've operated 100% SaaS.

<comment><USER6> My wild-ass-guess starting point is at least $2.5m/y with a 5 year commitment to make it anywhere near worth it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> As a consumer of a number of on-prem installs, I'd just like to add something positive in what will probably be a lot of negativity regarding selling your product on-prem.

The on-prem situation is evolving just as the SaaS/cloud world is evolving as well. Selling an on-prem product can be very lucrative if done correctly, and that can mean intentionally not selling to customers who don't have their act together. As more sophisticated customers install "private clouds" with OpenStack and the like, you can potentially have a SaaS on-prem use the OpenStack API natively and have a much better sales/maintenance story rather than boxing up a static VM and trying to get it or the customer to scale horizontally using static VM images and lots of configuration tweaking.

I do agree that monitoring/logging can be problematic, but sometimes there can be somewhat standard OSS offerings that can be plugged in if the customer already has a managed monitoring platform running keeping tabs on lots of other things. The more adaptable (literally adaptable -- adapters to various solutions) your software is due to good design, the easier it will be for you -- or even the customer -- to adapt it into their stack.

<comment><USER8> We went the other way, and it was far easier. Actually, our product is an Atlassian add-on, and Atlassian itself went from OnPremise to Cloud.

It was, however, a long migration for both Atlassian and the add-on vendors. It was necessary because the market wants to try products withut installing them. Now Atlassian is able to make cloud-level changes to their software: They can use CD, live analytics, mutualized authentication for all tenants, etc.

However, their API for cloud addons is, and will be forever, _completely_ different from the API for onpremise addons. It's a major difficulty for the ecosystem. Many vendors extract a .jar that they reuse in both onpremise and cloud addons, but the cloud runtime that connects this .jar to the cloud API is at least as big as the jar itself (because we don't benefit from the host's services such as user management, storage or logging).

OnPromise, which we started with, was however easier for us than Cloud. The customers, even enterprise ones (we have about 28 of them) are in charge of Ops, it cuts off half the work for us. And OnPromise is 3x more revenue for us per year, with the downside that it's a one-off, non-recurrent sale by default.

</comment></comment><comment><USER9> One thing I would call out: don't do CI to these people. Eat the pain and cut honest-to-goodness versions. Ideally, cut them on the quarter, so that your customers can comfortably expect a New Version to be available at a specific time.

I used to be on the other side of this desk, so.... trust me. It makes it easier when we can all refer to a specific version. You can throw us specific patches or whatever. From the developer standpoint, you're not delivering a continuously delivered system, you're delivering a "server app" of a specific version.

<comment><USER10> I think you mean "don't expect to do CD to these people".

CI is "developers check in code and everything is integrated daily".

CD adds "and then we push it out live if tests pass".

I've worked on software products that attempted CD, and it's not gotten a lot of great acceptance. Customers don't really want constant notifications about having to upgrade, except for very serious fixes. And I don't know many IT departments in big companies that are like, "sure, go ahead and auto-update".

CI, on the other hand, is wonderful. You don't have the mainline off in this broken state for weeks while you're adding features.

<comment><USER9> Whoops, yes, you're right. Misnomer. >.>

</comment></comment></comment><comment><USER11> This is a great post. We've been talking to a lot of people about going "on- prem". This post is right on in that the deployment is the relatively easy part. The ongoing operations is where you will get killed.

Luckily, for those that are thinking about doing this, for the end customers "on-prem" many times means single-tenant, private cloud (usually AWS) which makes things slightly easier (as the op mentions).

The vendors that do it right make their multi-tenant cloud app and "on-prem" environments as similar as possible. So that means containerizing and using an orchestration layer like Kubernetes or Mesos _everywhere_ (multi-tenant and single-tenant). Then you need to make sure you have a secure and scalable way to access all environments for upgrades, patches, support. We open sourced an SSH framework specifically for this purpose[1].

Bottom line: no special snowflakes.

Edit: for more info feel free to reach out: [http://gravitational.com/vendors.html](http://gravitational.com/vendors.html)

[1]: [http://gravitational.com/teleport/](http://gravitational.com/teleport/)

<comment><USER12> > for the end customers "on-prem" means single-tenant, private cloud (usually > AWS)

Nope. On prem means in their own private data center. Also possibly airgapped from the outside.

<comment><USER13> Depends on the customer. Often, the motivations that push them to demand on- prem can be fulfilled just as well by a less-demanding single-tenant SaaS solution; you just have to convince the customer's IT department that such a thing exists.

Sure, there are some (mostly in defense, finance, and a few other security- sensitive fields) where physical on-prem is non-negotiable, but in my experience customer demands for on-prem are far more likely to be driven by outdated and/or overly-conservative IT practices than by real need.

<comment><USER14> What you're describing is a private, separated installation on the Internet. In all cases "on-prem" is inside of a customer's datacenter/office.

<comment><USER15> I've learned to live with the meanings of things getting mangled. Once marketing requires that a definition change it's pretty much game over. You can try to fight it but quite often it's the marketing department and customer working together to change how something is defined because it's easier than changing outdated policies or thinking. At that point you're just a stick in the mud, pining for the good ol' days when clouds were just called "other people's computers".

</comment></comment></comment></comment></comment><comment><USER16> This topic is mildly amusing because I remember when all (or most) software was sold as "on-prem". Then everything moved to SaaS...and now everything is moving back to on-prem!

I used to work for Atlassian which made most of its money at the time I left in 2013 from on-prem software. It was low-touch, high-volume sales to people downloading and installing software on their own servers. They still sell a ton of it too.

If your stack is a hodge podge of web servers, shell scripts, and cron services, I think better advice would be based on how to make your application more packageable before moving to that model.

<comment><USER17> No, "everything" is not moving back on-prem, just like "everything" never moved to the cloud.

But a great many things _did_ move to the cloud, even more were conceived there, and practically all of them are going to stay there. You can successfully run a whole business of a very respectable size without managing even a single on-prem device, and that's great, and that's not going to change.

The push back to on-prem isn't a move, it's an expansion. Old/large/government orgs which for different good and bad but mostly immutable reasons can't let their data off-prem is getting interested. It's a new market, not a change in the old.

<comment><USER16> I agree it's not a dichotomy. However,it's also not a "new" market and it's not just dinosaur enterprises buying on-prem software.

</comment></comment></comment><comment><USER18> For those who haven't come across it before and have already dockerized there is a nice solution for some of these issues from replicated ([http://www.replicated.com](http://www.replicated.com)).

<comment><USER19> We use Replicated, and it was insanely easy to set up. We had an on-prem version ready to go in a few days. Definitely recommended!

<comment><USER20> We do what we can to ease the pain of going on-prem for modern SaaS companies :)

</comment></comment></comment><comment> old-gregg Ahh... my favorite subject! Can't resist :) SaaS companies are leaving a lot of money on the table by insisting to "making the world a better place" from their US-East AWS region ;-) The world, especially the enterprisey world of lucrative contracts, is much larger than that.

Gravitational [1] specializes in taking complex multi-server SaaS stacks into private cloud environments and providing ongoing management for them.

[1] [http://gravitational.com](http://gravitational.com) Full disclaimer: I work there.

<comment><USER2> In a similar vein, BitNami makes money licensing full-stack open source components with an integrated installer. I used it/them for a few years and while I wasn't smitten, it got the job done until something better came along. If you want a one-click installer for your mvc + db app, it might be worth looking at.

</comment></comment><comment><USER21> Strange that the author mentions two ways of doing this (managed here vs. managed there), and spends the rest of the article saying how those are not in any way fun, but never mentions the obvious third option: As Is.

I sell a self-hosted source-included license of Twiddla, as a single breakout of the current codebase, with the understanding that no further updates will be provided once we're all satisfied that you're up and running correctly. You can do whatever you like with the code, and I'm happy to sell you additional consulting time to help with what you're doing. But you're essentially on your own.

It pretty much dispenses with every concern in the article.

<comment><USER22> How do you deal with updates? Do you just sell them a newer version, like with MS Office major upgrades in the past?

<comment><USER21> No updates. Hence the "As Is."

They're buying the version of the website as it exists at the point of time when they buy it. The assumption being that it works for them now, it should continue working for them in the future, regardless of what direction the .com goes.

<comment><USER23> What about vulnerabilities then?

Or is it supposed that the customer use it behind a firewall / VPN solution?

<comment><USER21> In this case, we're talking about software built on the Microsoft stack, so most of that is Windows Update's job (patching servers manually isn't really something that needs to happen in this world).

As to vulnerabilities in the handful of 3rd party libraries that we use? In the 10 years that Twiddla has been around, we've had exactly zero cases where we had to patch something from our end for security reasons.

I guess there's something to be said about avoiding the tall skinny (and wobbly) tower of 3rd party dependencies that seems to be the norm these days in web app development.

<comment><USER23> > In the 10 years that Twiddla has been around, we've had exactly zero cases > where we had to patch something from our end for security reasons.

That is quite good compared to the rest of the industry. Nice work!

</comment></comment></comment></comment></comment></comment><comment><USER24> Every time someone tells you "You can buy a server for 2000$ why pay Amazon 4500$?" show him/her this article.

I've done on prem in the past, it's a real pain and I still remember it as a horrible experience.

That being said, I think it's pretty easy to combine. One of the things we had in the earlier days is hosting the CI and other build/compile servers @ the office and all the rest was in the cloud.

Even if you have some customer requiring something hosted on prem you can still host ALL OTHER clients on the cloud and this client on prem etc...

Good post.

<comment><USER25> Most of the points in this post. apply to hosting installs for your customer in "the cloud" too.

</comment></comment><comment><USER26> This is a subject near and dear to my heart, albeit from the "enterprise" side of the table, not the scrappy startup side.

I've spent a non-trivial amount of effort trying to convince software companies to spin an on-premise version of their software. Sometimes with success, and sometimes not. I understand that it's quite attractive to rely on AWS or GCE abstractions to the point where it would be nearly impossible to break it apart for installation on my boxes, but it seems like it's leaving quite a lot of money on the table.

There are perfectly valid reasons to require on-premise applications: in-house interpretation of regulatory requirements, protection of intellectual property, etc.

Of course, I have a right to ask and they have a right to say no, but I wish more companies would consider making an on-premise solution. (Slack, I'm looking in your direction. Please come take the money I'm currently giving to Atlassian.)

<comment><USER27> Given how much code is on github, I no longer think protection of intellectual property is a valid excuse. It may be a requirement from your boss.

<comment><USER17> That's not really how thinking about security works. "But everybody else is doing it" wasn't a valid argument in school, still isn't.

As a thought experiment, (ignoring the fact that it's not an appropriate store for such things, and only thinking about security towards third parties) how would you feel about a company storing your PII/medical records/credit card number in a private repo on GitHub?

That's how your boss thinks about the company's intellectual property.

<comment><USER27> Why would I feel any different if they stored it on Amazon cloud, github or on their own systems?

</comment></comment></comment></comment><comment><USER28> yes Yes YES! One thousand times yes! I previously worked at a SaaS mobile device management company (apperian) that took the on-prem plunge to score big enterprise / government contracts. The ops / support team quadrupled and there were so many headaches. This article nailed it.

<comment><USER29> Oh god yes.

Just wait until you're attempting to support a distributed ML system through some fucking idiot sysadmin (well, "sysadmin") who god only knows how he still has a job, but HE CANNOT RELIABLY USE SSH. Because of their security requirements (ie no internets for you, including package servers), getting updated packages onto their 4 year old redhat installs were a nightmare. And they wanted to run very high cpu requirement distributed solvers inside 4gb single processor vms. The fun was just endless.

</comment></comment><comment><USER30> Jeff Meyerson's recent interview with Julien Lemoin discusses the reasons Algolia has not created an on premises version. [spoiler: it is contrary to the strategic focus on performance, the same reason Algolia runs on metal it owns.]

[http://softwareengineeringdaily.com/2016/04/17/search- servic...](http://softwareengineeringdaily.com/2016/04/17/search-service- julien-lemoine-2/)

</comment><comment><USER31> Having done On-Prem in a past life, this article nails it on the head. It's a difficult problem to solve and the support costs are very real. You need a team (or teams) dedicated to OP if you're going to do it right. It can be lucrative and a huge differentiator for your product, but it is far from easy.

<comment><USER32> Great article, rings very true.

I'd say if you're in the early adopter phase and you desperately need big enterprise traction then do the deal with the devil and go on-premise.

Otherwise run a mile.

Worth noting is that sometimes a sales technique is to agree to on-premise (since your competitors probably won't) and then look for opportunities to remove it from the deal further down the line - the customer may even come to the conclusion themselves that its not a good idea.

</comment></comment><comment><USER14> As an operations person who has dealt with deployment of different "on-prem" software in the enterprise please keep in mind that smaller organizations have different needs then the larger enterprise. For a smaller organization a VMware disk image (commonly referred as an appliance) works quite well. But for larger organizations with operations folks we expect to be able to scale individual pieces of the stack or use our own managed infrastructure (e.g. MySQL, Redis, RabbitMQ).

If you're targeting the larger enterprise you can expect to have a somewhat more technical IT person to deal with, and if its a technical organization people who are keen on scaling the application/infrastructure independently.

<comment><USER33> > But for larger organizations with operations folks we expect to be able to > scale individual pieces of the stack or use our own managed infrastructure > (e.g. MySQL, Redis, RabbitMQ).

Puppet professional services consultant here. I work with lots of "enterprise" teams on "ops stuff" on-premise.

Between 2010 and 2016, I observed a change in teams interested in trying to scale individual components. Back in 2010/2011 teams did expect to scale out and manage individual components of the stack. Today, nearly every team I work with is like, "Oh you ship your own postgresql server in the product? Awesome, I'd much rather use that (and make it your problem)." Same is true for pretty much every component in the stack.

I don't know exactly why this is the case, but I have two suspicions. First, every Ops team I work with is has too much on their plate. Way too much. They're having trouble finding people to hire. They're happy to offload a potential maintenance issue, particularly if they're paying for the software. Second, this might be a reflection of crossing the chasm to the mainstream market sometime between 2011 and now, so the teams themselves might be inherently different.

What surprises me is that it doesn't really matter what industry the customer is in today. Government, technology, retail, insurance, finance, whatever... No team is interested in taking these maintenance issues on unless they _have_ to. Making a product they don't need to tune and scale component-by-component is a highly valued feature. Both for SaaS and On-prem products.

I think this "feature" is the common root of all the things cited as issues in the article. Making this stuff easy to operate is _hard_, hard enough for SaaS and _much harder_ when on-premise.

<comment><USER34> It depends on what the organisation has standardised on.

If there are people who know PostgreSQL already and they have the tooling for it, then they want to reuse that stack. If the organisation has standardised on MySQL/Oracle/SQL server/something else, then learning about and supporting PostgreSQL are additional headaches.

If PuppetDB was to support multiple backends, then you would find that every organisation would want to run on their own stack.

Ops has always been overloaded. That is the biggest reason why enterprise support contracts are a thing.

<comment><USER33> > If there are people who know PostgreSQL already and they have the tooling > for it, then they want to reuse that stack.

I haven't ran into these people in all of my experience on-site with paying customers. I'm not saying you're wrong, just that either I've gotten very lucky with my sample, or they do exist, but they don't really matter from a product perspective.

For example, I have run into a few Ops teams who interface with separate teams who have DB admin roles. Universally, the Ops team prefers the included DB "feature" because it allows them to avoid the overhead of dealing with the database. It's unfortunate the "overhead" in this case is collaborating with the DB admin team, but it's the reality I see on the ground.

> If PuppetDB was to support multiple backends, then you would find that every > organisation would want to run on their own stack.

I'm not sure that's true. I'm sure it's not true for _every_ organization. However, assuming it is true, I think it's a good example of why supporting multiple backends for PuppetDB would be a poor product decision. It wouldn't provide much value to Puppet the company or to their customers and it would increase the cost of support and maintenance tremendously for both parties.

The same applies to any on-premise software product. This is probably why pluggable backend data layers as a feature are so rare in on-premise commercial software products. Why bother?

</comment></comment></comment></comment><comment><USER35> After years working at a company that has a 10 year old on-prem and had a saas app as well, here is my POV on this:

On premise vs saas is a trade off in the type of customer support.

With on-prem, you do have support complicated by customers have unique infrastructure, and varying degrees of knowledge and post within their organization. Some people are adept, some are not. Some support keeps you screen sharing for hours, some do not.

In general for on-prem, support is done via your customer support app, professionally, as you're usually dealing with an IT department.

On the other hand, SaaS customer support volune/time is a measure of how often you break stuff for ALL (some, of you're lucky) of you're customers at the same time). Often an issue is experienced by many rather than a single person. "Always" (ish) it's your fault instead of being an issue of a customers configuration or infrastructure. Often Twitter becomes the public stomping ground for complaints, as you get end-users going to Twitter rather than an issue bumped up from an end user took their IT before reaching you.

In considering of you want to support on-prem, a key point is to keep your software simple. For example, optionally (and easily) logging to files instead of <third party here> to reduce requirements on external systems (elastic search).

Making the app as simple and easy to run as possible is pretty important. Definitely very strongly consider if you need to rely on that saas app for your App to run.

<comment><USER36> > In considering of you want to support on-prem, a key point is to keep your > software simple. For example, optionally (and easily) logging to files > instead of <third party here> to reduce requirements on external systems > (elastic search).

We have extensive experience doing this over here, and this is _key_. Keep things even simpler than you think they could ever be, because "simple" times gazillions produces terrific economies of scale.

During interviews I'm often asked if I have experience on a product "at scale", by which interviewers often suppose it can only mean some typically tiered load balancers/front-end code/backend code/data persistence and you spin up new dynos/AWS of what is really (taken as a whole) a single cohesive application to face demand, and ultimately get dismissive when I tell them I'm not working on a 1Mreq/min product... but there's a whole other orthogonal dimension to "scale" which most products have firmly locked to 1, and believe me, everything suddenly follows a square law when your code and architecture can have an impact on _each_ dimension, especially the one that involves humans that don't have the level of intimacy with neither your product, team, or methods.

</comment></comment><comment><USER37> Doing on prem is hard but worth it. The sales cycles look different than SAAS but I don't see it going anywhere for a long time.

The key to this is a field team and a good support infrastructure.

Operationalizing it is half of it which is (echoing another poster here) the key to making it economical.

Our on prem stuff targets hadoop/spark clusters though so typically there's already ops folks in place who understand how our stuff works. This obviously won't be true for all scenarios though..

</comment><comment><USER38> Depends on your customers, but a decent amount of the stuff complained about here is stuff you may need to do in your SaaS anyway even if it's _not_ deployed on-prem. The article mentions that in the SaaS version you update daily and don't maintain 6-month-old versions, but that's often not really realistic. If customers depend on stable functionality and versions, the fact that you control the hosted install doesn't mean you can just break things whenever you want. Yes, you can more easily do _careful_ , planned updates since you control the whole environment. And you can run off of one integrated code-base. But you often need to conceptually support "6-month-old versions" in the sense of having announced and planned upgrade and migration paths, supporting parallel versions of APIs, etc. Many of the problems are at least similar, though not identical. Now if you can use a Facebook-style "move fast and break things" approach with no care for versioning or legacy support, you can bypass all of those. But if you were in a market where you had potential on-premises customers in the first place, how often is that true?

</comment><comment><USER39> Just use replicated. [http://replicated.com](http://replicated.com). Easiest way to on-premify your SaaS app.

</comment><comment><USER40> I wonder if there's an inverse 'So you wanna go SaaS' for on-prem only companies...

<comment><USER41> Going to SaaS can be quite an issue depending on the reliability of the company developing the software. One of the company I'm dealing with as a reseller had the bad habit of delivering releases with semi-critical issues and even regression bugs, consequently with my colleagues we decided to act as a buffer, doing a pass of QA ourselves, and depending on the results making the versions available or not to our customers. Sometimes it took one year before getting an good enough release. Quite annoying to do this ourselves, but at least our customers are satisfied with the quality.

Now a year ago the partner decided to deliver a SaaS version, which made completely sense commercially. Then the SaaS became public a month ago and we keep encountering critical issues, like features not working, translation files older than the last on-prem release, or even impossibility to log in because somebody installed a patch and never checked anything after (and never told us about it either). But this time we cannot buffer anything, so they are basically shooting themselves in the foot.

</comment></comment><comment><USER42> Things I learned after 10 years of dealing with enterprise customers.

1\. They want on premise.

2\. They want key account people to talk to.

You don't need multi tenancy. You often get your own server to run on AND a local ops guy. It's a bit like an exclusive cloud.

Yes, the deployments are a bit harder, since you often can't simply drop in a new version over the internet. This is why you need more ops to handle this all.

But if I wanted to sell to enterprises I wouldn't got into the cloud in the first few years after starting the company.

If the system works fine, it's a no-brainer to deploy it in the cloud and you already have all the ops people to maintain this...

</comment><comment><USER43> Has any anybody here considered leveraging the on prem offerings of cloud providers, e.g., Azure on prem ([http://www.geekwire.com/2015/microsoft- brings-azure-on-premi...](http://www.geekwire.com/2015/microsoft-brings-azure- on-premises-with-new-services/)) or Bluemix local ([http://www.ibm.com/cloud- computing/bluemix/local/](http://www.ibm.com/cloud-computing/bluemix/local/))?

</comment><comment><USER12> > If they suck so much, why do them? > Money.

Yap.

> when you move to any sort of on-prem model, your operational and support > problems are multiplied.

No kidding. Multiplied by orders of magnitude. Difference between looking up a query in Splunk vs directing someone possibly less technical to ssh in try to read logs to you via phone and figure out the problem from that. Or even worse, having to urgently put people on the plane to fly them onsite to solve the problem. And often when they return they can't bring any logs with them.

</comment><comment><USER44> On-premise install can be marred with problems. I have a case where the customer's IT refused to grant access to their network. The PM on the business side had to start Webex, shared his desktop, and allowed outside access to do the install via his desktop. Talk about punching a huge hole through their firewall.

<comment><USER45> ...and he would probably have been disciplined for it or at least had a stern talking to from IT.

This is a very common situation and in fact is the major reason behind them wanting on-premise solutions. You don't want your SaaS talking to the big wide world.

If you're thinking you should be able to do on-premise installations remotely... its already gone over your head!

</comment></comment><comment><USER46> CoreOS actually makes this significantly better with their Cloud Config capabilities. With CoreOS and Docker, we've successfully deployed this at a number of companies.

With that said, there has been plenty of support to be handled, and we need to get better at doing multi-node deploys, but we're learning. :)

<comment><USER47> Well, you're quite lucky to be allowed to use CoreOS. In our case, only a minority of customers didn't want to dictate the distro to be used.

In one extreme case, we had to install on SLES 10 (in 2014), _without root or sudo_ , and then hand over the machines, since we weren't allowed direct access to the production system. And maintenance involved sitting with one of their sysadmins and telling him what to do :)

</comment></comment><comment><USER48> This is my life right now. Fighting customers for on-site installs. This hits too close to home...

</comment><comment><USER49> As an employee at an enterprise that often asks SaaS companies for on-prem solutions... this is very on point. That said, we do pay _a lot_.

</comment><comment><USER50> Going on-prem also means building a different system, it has to be more streamlined, self contained and serviceable.

The quality of this is tested once the customer wants to upgrade his system from version X to version Y.

</comment><comment><USER51> We[1] drive the bulk of our revenue with on-prem. Many companies prefer to keep their SSH key management in house, and we actually count on that.

However, we've invested a LOT of time into making our distributable a simple daemon. It's very easy to manage and install. We offer two on-prem versions: one is _Pro_ which provides the basics (starts at around $3,500), and one is _Enterprise_ which costs a lot more and supports external Redis, multiple app servers, web servers, LDAP integration, etc. Sales between the two are split approximately 30/70 in terms of revenue. In other words, we make a lot more on the Enterprise versions, but we sell less of them and the support costs are definitely higher.

Just my 2c - but for us, on-prem has been a huge win and has taken us to profitability. In truth, however, we've probably focused too much on on-prem and not given enough focus to SaaS/cloud.

For a startup that's just starting to hit profitability, we've actually been very happy with focusing on on-premise over SaaS, in contrast to the article, but our product was (re)designed with both scenarios in mind from the very beginning. We actually re-wrote the entire product before offering an on-prem version.

In other words, just as described in the article: making technology changes like SQL to something else 'on the fly' might be hard but not impossible with SaaS... but with on-premises, it's almost impossible to work through hundreds of on-prem installations of some previously chosen tech, and the need for data migration, installs of new supporting packages, etc. I used to work as a tech consultant for a big company and one of our huge clients decided to upgrade all of their on-site journaling systems (running a PII-300!) from Windows to Linux. Remotely. Through an ISDN. Yes, this is possible if you have multiple drives available in the box with careful syslinux. Yes, it's also pretty insane. (We had about 95% success across around 10,000 stores worldwide.) Changing horses in the middle of the race is something to avoid where possible.

It's easy to see that you're probably going to be stuck with your early technology choices if you go on-premise, unless you really build fantastic, auto-data-migration tooling that never fails, so make wise decisions and stick with SaaS until you're certain that you are sticking with your tech choices.

(We don't differentiate between "on-prem" in your datacenter versus your VPC or (your) cloud. To us, you're installing/managing/running it and we're not, so, to us, that's on-prem. Other providers probably define this differently.)

1\. [https://userify.com](https://userify.com) (sudo and SSH public key management.)

</comment><comment><USER52> Synology DiskStations are an affordable option (<$1000) for on-prem data storage accessible to your web application. They run a standard LAMP stack out of the box (basic database and file storage) and have redundant/RAID storage.

A few tips from experience: if you can get them to put it on a dedicated IP, even better; use Synology firewall to limit access to your servers IPs, or VPN (do not leave on public net, because ransomware); set to auto-update the OS (because the customer never will!); still have another backup (even a USB- attached 1TB solid state drive, but ideally another physical location); disable all unused services (to limit potential exploits); if customer allows, give them a user and you a user - enable logging and now you can demonstrate if/when you had to access their box for maintenance (feel good factor)

<comment><USER53> > Synology DiskStations are an affordable option (<$1000) for on-prem data > storage accessible to your web application. They run a standard LAMP stack > out of the box (basic database and file storage) and have redundant/RAID > storage.

You're joking right? What enterprise would install a consumer NAS in their data center to use for " _data storage accessible to your web application_ "?

[1]: [http://www.amazon.com/Synology-DiskStation-Diskless- Attached...](http://www.amazon.com/Synology-DiskStation-Diskless-Attached- DS1513/dp/B00CM9K7E6)

<comment><USER52> Can you explain? Sure, they're marketed to consumers because their audience is largely there, but if configured securely (to only talk to your infrastructure etc) offer a very affordable option to store data behind a customer's walls.

"In their data center" implies you're thinking large enterprises. Small businesses/industries may have requirements to keep data on-prem but without enterprise budgets.

(Your link returns 404 for me)

<comment><USER53> > Can you explain? Sure, they're marketed to consumers because their audience > is largely there, but if configured securely (to only talk to your > infrastructure etc) offer a very affordable option to store data behind a > customer's walls.

Couple of separate points.

First off forget "affordable". The customer that's paying for an on site version of something has a very different definition of "affordable" than whatever you're considering. Something that costs $500 literally rounds to zero.

Second, nobody, and I mean NOBODY, is going to let you plug your own box onto their network to watch some other box that you've deployed on their network. In fact, you're not going to have your app on your own box there either. The vast majority of customers will want to deploy your software on whatever version of RHEL they have a licenses for (or CentOS if they're "modern"). At best you'll deploy your app in a VM that (hopefulyy) plays nice with whatever VM kit they're using.

Third, that consumer NAS won't fit in a rack. Is it just going to be plugged in to a wall socket with a cross over cable connecting to your "app box"?

> (Your link returns 404 for me)

Sorry about that. I chopped off the rest of the gunk at the end of the URL and ended up taking too much off.

<comment><USER54> I think Synology has a rack mounted product, but it is still a terrible idea ;)</comment></comment></comment></comment></comment>


Breaking the Web's Cookie Jar - <AUTHOR> http://www.codinghorror.com/blog/2010/11/breaking-the-webs-cookie-jar.html

<comment><USER2> Atwood recommends only browsing 'anonymously' when on public, unencrypted networks, but that's a lot harder than it sounds. A facebook 'like' widget (even if you don't click it) on the news site you're using anonymously can be enough to get your Facebook info sent over the network.

<comment><USER3> Only if you're logged into Facebook. Perhaps a Firefox extension to segment cookie stores based on your IP is in order?

</comment></comment><comment><USER4> "Lobby the websites you use to offer HTTPS browsing."

The irony is that codinghorror.com and stackoverflow.com (the two most prominent Jeff Atwood's web sites) do NOT support HTTPS.

<https://www.codinghorror.com/> simply times out. <https://stackoverflow.com/> greets me with "The site's security certificate is not trusted!" and then further with Access Denied.

</comment><comment><USER5> This has nothing to do with HTTP, nothing to do with cookies, nothing to do with Wifi, nothing to do with capturing packets being 'easier' (?!?), nothing that is easier since 2003.

It has to do with a very simple concept that many do not seem to understand: If you are on the same network as somebody else, and you are not using an SSL connection, other users on the network will see everything. And further, even if you are using SSL, if you aren't checking the key sigs, they can again see everything.

Cookies are simple and elegant and are not the problem - the solutions have existed for almost 20 years.

Firesheep is great because it is not only switching on users who had no clue, but also developers who have no clue.

</comment><comment><USER6> I think Atwood seriously understates the innovation behind Firesheep. The vulnerabilities are not new. Proof of concept code has been out there. It's all in the execution. Packaging an exploit as a voyeuristic game has made it rise to the top of securities discussions since it was released.

</comment><comment><USER7> One mitigating measure would be to use secure VPN. Traffic from the VPN to the destination would still be unencrypted, but would eliminate drive-by hackers.</comment>


UK Lulzsec hacker Ryan Ackroyd pleads guilty - <AUTHOR> http://www.bbc.co.uk/news/technology-22079709 <comment><USER2> It strikes me as interesting that probably a year ago LulZSec was held as a some all-consuming, faceless group of digital wizards, (that naturally needed significant funding increases to combat.) - the press, the wrong footed FBI / Police, and ourselves accepted that they were a real threat.

It seems less so to have a mundane trial with mundane breaches of a mundane law.

We have built houses of straw, and the strength of the houses is being clearly illustrated (perhaps LulzSec achieveing one of its goals then?).

that reminds me, must change the default password on my router.

</comment><comment><USER3> Personal pet peeve: It's 2013, and we're still calling these cyber criminals "hackers".

This story is shared on ... HACKER News. Are we all criminals aficionados here?

<comment><USER4> Both meanings are legitimate uses of the word, "hacker". Those who matter can tell which one is being used by the context.

Honestly, I think arguing for using the word "cracker" in place of "hacker" has a Stallman-esque feeling to it, now.

<comment><USER5> "Those who matter?" Hopefully you meant "those who understand the way people here use the term," which would be both more correct and less disingenuous.

I agree, though, that the terminology argument is unhelpful and stale. Unfortunately, pedantic terminology attacks are often a lot easier than constructive debate or discussion.</comment></comment></comment>


Antipode Map (dig a tunnel through the earth, where do you end up) - <AUTHOR> http://www.findlatitudeandlongitude.com/antipode-map/#.V1XLDZMrJE4 <comment><USER2> Oh that is fun, too bad if you dig straight down from Silicon Valley you end up in the Indian Ocean. Of course it would make an excellent hyperloop route, San Francisco to Mumbai in only 10 hours :-)</comment>


Unicorn bracketology – which startup unicorn is the most undervalued? - <AUTHOR> https://www.cbinsights.com/research-unicorn-bracket <comment><USER2> Interesting approach.

<comment><AUTHOR> Thanks. It's mostly for fun but given the # of responses we've received, it'll be interesting to see if the wisdom of crowds holds.</comment></comment>


The Brief - A daily briefing of technology news worth caring about - <AUTHOR> http://thebrief.io

<comment><USER2> Thanks. This is similar to <http://evening-edition.com> . A nice clean website written intelligently without a lot of fluff.

</comment><comment><USER3> Could this be better than user-generated content? What happens when the maintainer/editor gets bored / finds another hobby?</comment>


How Facebook dug deep within Android to fix its mobile app - <AUTHOR> http://arstechnica.com/business/2013/03/how-facebook-dug-deep-within-android-to-fix-its-mobile-app/ <comment><USER2> Related discussion: <http://news.ycombinator.com/item?id=5321634>

</comment><comment><USER3> How much is Facebook paying ArsTechnica for these infomercials?

<comment><USER4> It is clearly just a write up of the Facebook blog post. So I doubt anyone.</comment></comment>


Venezuela's central bank holding Bitcoin is just crazy enough to work - <AUTHOR> https://decrypt.co/9697/venezuela-central-bank-holding-bitcoin-just-crazy-enough-work <comment><USER2> Accurate title!</comment>


Make Donald Trump say (almost) anything - <AUTHOR> http://www.mishmasher.com <comment><USER2> Thumbs up

<comment><AUTHOR> [https://www.youtube.com/watch?v=UOoIBMXPgro](https://www.youtube.com/watch?v=UOoIBMXPgro)</comment></comment>


Show HN: DropPy – Python-based automation via drag and drop, for macOS - <AUTHOR> https://droppyapp.com <comment><AUTHOR> I wrote DropPy to gain access to all the items provided by macOS' drag & drop implementation. Then I pipe the results through some simple, reusable Python classes.

Would love any feedback!</comment>


Ask HN: How to deal with big existing code base when you are new to the team - <AUTHOR> Context - I am just starting with a team as a new member which have huge ReactJS code base. I have only basic understanding of ReactJS.<p>Is there any mental modal, tips, experience which I can follow to speed up my understanding of framework as well as code base and start contributing ASAP? <comment><USER2> Start with understanding what business problem the app solves.

Understand roles in application (admin, user, etc.) Click through the application, do list of all URLs/pages, describe what you think it does and consult with PO/team to clarify understanding.

Then learn where data comes in/out and in what format. Study schema of database (hint: ERD diagrams). Then study business API (schema, endpoints, graphiql).

Then you can move to frontend. Frontend is easy after you understand all above :P You will basically know what it does/should do, so you don't even need to read code.

React code is very modular so it's easy to navigate, to find where to start simply use React Devtools (shows component name on hover), then you should be able to navigate rest of code via IDE/editor.

If codebase is of high quality it should also have React Styleguidist or Storybook with most components to play with.

To understand react it's best to write it yourself:

      * https://jasonformat.com/wtf-is-jsx/
      * https://dev.to/ameerthehacker/build-your-own-react-in-90-lines-of-javascript-1je2
      * https://pomb.us/build-your-own-react/

</comment><comment><USER3> Get the application working locally. You will likely find a lot of old half- written doc that doesn't work anymore, and other developers have tricks and changes they made on their local machine to get things running. You should get it all running yourself and document what you did for the next developer.

<comment><USER4> My team's code hasn't been able to run locally for at least 7 years. All development consists of committing changes to SVN trunk and running a Hudson build to update a shared dev server. We have hundreds of commits per day, mostly with unhelpful messages like "up".

halp

<comment><USER5> I cannot agree with the GP post more, you should be able to reproduce a working environment from source and environmental config. If you cannot you may want to try getting your team and your management to see the value in investing in doing so. When I took my latest contract, I literally walked into an environment where developers where pushing to the same server, debugging on the same server and generally stomping all over each other. I felt like I was developing in the 90's all over again. They did not see that it was a huge productivity killer. I took the time to automate the development environment to the point where each developer was able to run a script and have a fully local dev environment. Isolated DB, isolated server, isolated LDAP instance everything needed to run the environment completely disconnected. It is really not that hard to go thru the process of setting everything up and capturing the process in scripts, even something as simple as shell scripts or powershell scripts are better than having the dev environment fail, and having to stop progress while everyone scrambles to get an environment back up.

As for the topic at hand, I always find the entry point of the application, fire up the debugger and walk thru the main workflows of the application. This generally gives me enough of a mental map of the app to be able to dig into an area when I get a bug or feature request. The debugger allows you to break on areas you don't understand and work thru them in more detail.

Total tangent: this is why I detest and will not whiteboard in interviews, I am a debugger forward developer, it is how I reason about code. I think behind the compiler (or interpreter) the debugger is the second most important tool in a developers toolbox. It's sole purpose is to help a developer understand what is going on at runtime. It is hands down the best way to learn a new codebase.

<comment><USER4> Any advice on what to do if the code is heavily entangled with AWS?

<comment><USER5> You should have development or pre-prod versions of your AWS services, for those areas local dev environments should point to those endpoints. Ideally each dev would have their own AWS sandbox, but I get it that sometimes that is an impractical solution so what I would personally do, is create a nightly (or unstable) instance where one can test their code against the latest code base and push needed changes to, a stable instance where known stable features and bug fixes get deployed and then a release instance where testers can test against items deemed fit to go out in the next release. Developers should switch their local to unstable and stable endpoints based on their needs as well as the condition of unstable. If someone breaks unstable, other developers can still progress against stable they just cannot push to it. So think of stable as can read but cannot write. Once unstable is back up, they can push any service changes they need to up to AWS. As a side note, it is the responsibility of whoever broke unstable to get it back up and running for the other devs.

</comment></comment></comment></comment></comment><comment><USER6> I don't know ReactJS so the below is just generic advice. That said there are a few solid starting options that I have used at different times in my career:

1) start with tests - reading existing tests, adding tests, fixing tests which fail etc. Any of these should really help give you some threads to unpick to get started in understanding the bigger picture. I don't think I've ever seen a dev shop where an old hand would turn down a PR review from a new engineer who was adding new test coverage.

2) start with backlog - try implement some dusty feature from the backlog that has been sitting there for a while. One place I worked I started with "Convert 100+ functions from deprecated format A to new shiney shiney format B". Another was "fix the thing which isn't compiling on new platform X". Another was "fix the millions of warnings we get when we turn warnings on". These are really unimaginably boring tasks in and of themselves, but focused me on a few different things which are useful to know early (how to push a PR, how tests work, how the build infrastructure works etc) and get you started contributing something useful right away.

3)Start with infrastructure - I like the suggestion which someone else has made of getting the app to run locally. I would extend that to fixing a piece of broken dev tooling. If you're infrastructure-minded, this can be a nice way to start and win you some goodwill with other devs.

Don't think you need to understand everything to make a big contribution though. A lot of coding isn't about being an expert it's about putting in the work. Observe code reviews, see what gets merged and in particular make sure you understand and take on board why PRs get rejected/resubmitted.

One thing to bear in mind is you're going to be a bit of a tax on your colleagues while getting up to speed. Help them (and yourself) by making your PRs shorter and simpler initially to make sure you're on track. (eg in the example above, don't do 100 functions in one pr, do one, submit it, ask for feedback, then do more).

<comment><USER6> oh also look at the repo history to know who the real major contributors are. You don't want to waste these people's time, but buying them the occasional coffee and asking good questions can be worth its weight in gold. `git shortlog -ns --no-merges` is worth looking at.

</comment></comment><comment><USER7> My coworkers at every new place I work at make jokes at me for doing this, but I usually identify reference code I can print off right away.

For instance, once you finish a feature or task, identify the most important bits that happen. Create a gist of it on github.com, then promptly print it. It needs to fit on one or two pages at most, delete stuff that's not relevant. Likewise, if you have to learn their styling guidelines and naming, print off the most important parts.

Stuck on javascript concepts? Print the parts you struggle on. Stuck on lifecycle methods? Print the diagram. Constantly flipping between jira tickets? Print them.

The reason why this works is because you apply the concepts of space repetition to pick things up quickly. Your forced to chunk the code snippets in print form in a meaningful manner

As time goes on just write reusable code that you can copy later for different parts of the app. You won't need to print anything anymore because its commited to memory.

Also I make small side projects with coding patterns I can copy paste easily too

</comment><comment><USER8> Start with a small feature. Like a total count. Look what list of objects is being counted.

Make a note of the object's type.

Find what function is retrieving those objects say A list of users.

What is making the AJAX call to get those users.

Are there any tests?

</comment><comment><USER9> Take a look at the completed merge requests/features. If any developer of that team was any good, there would be plenty of well-written merge requests and commits.

With that, you would know what to touch and when.

When in doubt, check tests, the feature itself and the git history.

If you are new to ReactJS, also try to look for a mentor inside your company/team. They don't need to to active mentoring, but more like a person you can fall back to, and that enjoys doing mentoring and does it well.

BTW, Good luck on your new job!

</comment><comment><USER10> I'm not familiar with ReactJS, sadly but I often use breakpoint debugging and IO (eg: print statements, drawing shapes, logging, etc.) to help get a feel for the common data flow quickly. This lets me make a hypothesis like "when I click on this button, does this line get hit?" or "does this series of functions get called?".

Sadly, I'm not 100% what that would look like in your situation.

</comment><comment><USER11> There are lots of good tips, I'll add mine: I always ask for a few simpler bugs or small feature requests that I can use to learn the codebase. For me, it's easier to dive in when I have a smaller surface to focus on.

</comment><comment><USER12> I wrote a lot of sequence diagrams for tasks I worked on and saved the interesting ones. Also, finding somebody senior to explain a module pays off big time. Also, learn the database schema: all an app really does is manipulate data

</comment><comment><USER13> Pick a part (like maybe the part that you're first going to have to work on). Get a tour of that part from someone on the team. Then dive into that part. When you have questions, ask.</comment>