The Napier88 Persistent Programming Language and Environment (1988) [pdf] - <AUTHOR> https://cs.adelaide.edu.au/users/dave/papers/napier88.overview.pdf <comment><USER2> Does anyone here have previous experience with this programming system, and how it would be implemented today?

<comment> david-given Well, I went to St.Andrews during the Napier days.

I didn't use Napier myself, but some of my colleagues did, and there were frequent cries of 'aaargh! My persistent store has been corrupted!' followed by rebuilding it from source.

But that's not really a criticism of the language itself, merely the implementation, and I didn't have enough experience on it to usefully comment.

The university was deeply into pure research, doing stuff like pure research on garbage collectors and theorem provers in Prolog (one of the lecturers wrote a theorem prover package for the Mac that we used a lot. It was all in Prolog. INCLUDING THE USER INTERFACE). But they were less good at the practical aspects of software engineering; I remember one of the lecturers arguing that we because our DEC Alpha workstations had 32MB of RAM, therefore a twin-space garbage collector of 16MB per space would be optimal...

 _I_ did the persistence parts of the course in Smalltalk, which was so much simpler.

The paper references PS-Algol and S-Algol. I did a lot of S-Algol; it was a teaching language used by Glasgow and St.Andrews for basic algorithms courses, the intention being to decouple the algorithm from the implementation. I quite liked it, but --- remember how I said that practical software engineering at St.Andrews wasn't so great? The Mac version had an IDE which _did not support cursor key movement_. The Unix version _didn 't have a garbage collector_ (it just hadn't been implemented).

Good times, good times...</comment></comment>


Parsons code - <AUTHOR> https://en.wikipedia.org/wiki/Parsons_code <comment><USER2> Wrote a quick perl script that implements the functionality of the wikipedia image:

[https://pastebin.com/dhD5b90C](https://pastebin.com/dhD5b90C)

</comment><comment><USER3> Kinda reminds me of the notation scheme someone was trying to implement for DJ scratching 15 or so years ago.

<comment><USER4> I remembered when I first learned that and how mind blowing it was to help learn complex scratches. I dug it up. Turntablist Transcription Method, TTM: [http://www.studioscratches.com/scratchy-100-ttm- turntablist-...](http://www.studioscratches.com/scratchy-100-ttm-turntablist- transcription-method-explained/)

</comment></comment><comment><USER5> I'm very interested in music but never took a class or learned notation or theory. This appeals to me because it has always irked me that people would write down songs like Twinkle Twinkle Little Star or Happy Birthday as if they start on certain notes. They don't. They start on whatever frequency you want. The frequencies and lengths afterward are relative to the first _whatever-you- want-to-call-it_.

</comment><comment><USER6> I wrote about Parsons Code a few weeks ago in my Chord Progressions dataset documentation!

[https://peterburk.github.io/chordProgressions/index.html](https://peterburk.github.io/chordProgressions/index.html)

There are only 81 possible Parsons Codes for a 4-chord song.

</comment><comment><USER7> So that's the name of what I spent hours doing while trying to solve that sunken ship puzzle on The Witness.

</comment><comment><USER8> I have been mentally trying to devise a scheme for doing this for years because I hear music as the position of the notes moving relatively. From this I dance to the relative notions but I have had difficult writing it out, this is perfect!

</comment><comment><USER9> Cool – I sometimes used a notation like this (the visual form of this) myself to (attempt to) remember melodies I heard on the radio... before Shazam existed

</comment><comment><USER10> I would be interested in hearing more about this technology being used in practice. Are these codes primarily "hand written" by an individual listener or are they encoded by computers?

<comment><USER11> It's typically handwritten because computers aren't very good at transcribing music. You can use it to search for music: [http://www.musipedia.org/melodic_contour.html](http://www.musipedia.org/melodic_contour.html)

<comment><USER12> Sure, but I'd love to be able to, say, input a midi file and get Parsons codes for all the tracks.

<comment><USER13> Oh, that would be pretty easy. MIDI's not a difficult format to parse, and I'm sure there are libraries already written that would just dump out lists of note events, or something.

<comment><USER11> It depends, MIDI files can be complicated. I don't think it's easy to programmatically isolate the melody in the general case.

<comment><USER13> Ah, yes, that's true. Finding the melody, tracing it across different instruments and such, could be difficult, and that depends on how the music is structured.

I should've said that a naive version of it would be easy (like a channel- wise, instrument-wise, or track-wise code).

<comment><USER12> Agreed, it'd be easy if the melodies are already isolated. It'd be an interesting challenge to isolate them out of a combined track!

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Doesn't mention time signatures, purposely ignores key, but also doesn't represent note interval. How exactly does this facilitate search?

<comment><USER15> Exactly for those reasons.

Most people can't pick out intervals by ear, but they can manage "higher" "lower" or "the same".

</comment></comment><comment><USER16> There should be a babeljs converter for this.</comment>


Cloud Atlas 'astonishingly different' in US and UK editions, study finds - <AUTHOR> https://www.theguardian.com/books/2016/aug/10/cloud-atlas-astonishingly-different-in-us-and-uk-editions-study-finds <comment><USER2> I remember studying _" The Catcher in the Rye"_ back in high-school, and before we started to read we were provided with a few critical analysis pieces for orientation. One of these was a discussion of the difference between the UK and American editions the key of which was the omission of _italics_ in the former. Now anybody who's read TCITR will know the importance of italics to the narrative. The UK editor didn't believe they were important, perhaps objected to them on aesthetic grounds and so they were stripped out. We did of course reading the re-released, American edition, printed as the author intended.

<comment><USER3> Apropos which, one of the whackinesses of modern publishing is that Adobe InDesign, the publishing package that has mostly displaced Quark in the typesetting biz, frequently loses italics when importing a Microsoft Word document. And if the author suffers from middle-aged memory issues (as is quite common, because a "young" author is anyone under 45) there's a good chance they'll forget to put them back in when they're checking the page proofs.

</comment></comment><comment><USER3> The reason why this happened is explained in the article itself; it's surprisingly common.

TL:DR; books are 'sold' by authors as intellectual property reproduction rights in distinct territories. Historically it used to be too expensive to ship lumps of paper across oceans, so the North American and UK/European English language rights were handled by local publishers in the USA and UK, and smart authors and literary agents unbundled them and sold them separately (rather than relying on a publishing house's sub-rights department to outsource the rights they can't make use of).

A smart author then goes and kicks butt so that their US editor talks to their UK editor (or vice versa), agree who's going to take lead on copy editing and typesetting, and then ensures that the author only has to double-check one version of the book as it goes through production. Note that publishers are usually happy to do this (except in KidLit/YA/educational material when tailoring to fit local national spelling/grammar rules is manadatory) because it's a lot less effort for one of them to just buy the InDesign files and slap a new cover on the product, and a lot less stress for the author (checking copy edits/page proofs eats multiple weeks during which the author would rather be writing the next book: you don't get paid for checking extra sets of edits).

Where this breaks down: author is inexperienced (as Mitchell was at the time), or one of the publishers fucks up (as also happened in this case), or there's a big dislocation in the schedule for the book and one publisher is left racing to catch up with another one to hit the same publication date (which they always try to do, in order to minimize the risk of retail imports eating their launch week sales -- the First Sale doctrine means you can't stop a customer from legally buying a copy in another country and paying for it to be shipped to them, and Amazon makes this _really easy_ ).

It's less of a problem these days as most of the major houses moved to their own brain-dead version of all-electronic production workflow in the past couple of years (mutter, grumble, Word change tracking and PDFs and email like it's 1995, baby). It took them so long because many authors are eccentric recluses who still insist on using fountain pens to make chicken tracks on paper, or WordStar 4.0 for DOS. (And, embarrassingly, you can't ignore them unless you want to kiss goodbye to GRRM's next installment in "Game of Thrones", for example: writing novels is one of the last truly artisanal art forms to still exist and have commercial potential.) Nevertheless, these cock- ups still happen even today: all it takes is editor A having a snit and refusing to talk to editor B, or having a wholly unscheduled stroke and being off-work for three months in a department that's already overstretched, and everything comes off the rails.

Source: this is my life.

<comment><USER4> > It's less of a problem these days as most of the major houses moved to their > own brain-dead version of all-electronic production workflow in the past > couple of years (mutter, grumble, Word change tracking and PDFs and email > like it's 1995, baby).

Hmmm... I'm curious about this now, is the workflow the same for reflowable ebook and dead tree versions of the book? My guess would be that the best case scenario would be some plain text format with markup, but I doubt either authors or editors are doing that, and I can't think of what format that would even be (LaTeX not working so well for reflow).

</comment></comment><comment><USER5> "...I have a very low faff-tolerance threshold..."

Love that. I do some work as a fiction editor and I'm often amazed at how calm authors are about quite large changes occurring in their work. They can be obsessive about tiny things like a single word and then casually change the order of chapters, or cut whole sections without losing any sleep.</comment>


Philips Hue Bridge v1 online services will be shut off after April 2020 - <AUTHOR> https://twitter.com/tweethue/status/1235844699253956609 <comment><USER3> my problem with being too critical of this is that hue is very open, very well documented and nothing else is.

declaring that you'll never buy another philips product ever again because they shut off _hosted services_ support for a relatively flawed v1 device -- when a v2 device is available for £25 -- is pretty petulant imo. it will still work on your lan.

i've got 15 hue bulbs and a hue bridge but i don't use any of their cloud services. i control them via zigbee light switches on a raspi running homeassistant paired to the hue hub without any "hue cloud account" or any reliance on internet access or anything of the sort.

i don't know of another mainstream brand who will even begin to allow that without significant vendor lock-in.

<comment><USER4> Lifx has an entirely open and very well documented local UDP API, and a pretty open and well documented REST API.

On top of that, no need for a bridge or base station. They can operate entirely locally with no need for a mother ship if you don't need to control them away from home.

I make pretty heavy use of the UDP API from my local server and help maintain a Go library.

<comment><USER5> Those are WiFi though, no? Not exactly the same thing. Personally, I prefer a hub/bridge and then a mesh network for Home Automation. I've got Hue, Z-Wave, and WeMo. I much prefer the experience with the first two now.

<comment><USER6> It's all just different flavours of radio waves.

<comment><USER7> Wifi, Bluetooth, cellular, bespoke solutions, etc. are all "just radio waves" yet entail a vast spectrum of engineering and business requirements including cost, power usage, implementation complexity, reliability, interoperability, and range.

</comment></comment></comment></comment></comment><comment><USER8> Imagine you are designing the web server for some hardware like this.

You might write it in Go, dockerized and hosted it in Kubernetes in Google Cloud. You might use a hosted mongo db and 3rd party auth service.

Now in 30 years time, Google Cloud will probably no longer exist, your database API will have changed beyond recognition, and your auth service has closed down. IPv4 no longer exists and your hardware depends on it so you have to build all kinds of compat layers. You won't be able to get hold of all the packages for your server side code. The Go compiler probably won't even run on an OS 30 years from now. Your staff have retired, and nobody new wants to learn a programming language from 30 years ago.

Maintaining a server side API, even a really simple one, pretty much costs 1 fulltime person forever.

This hasn't always been the case. If you had written your code as a self- contained DOS executable back in 1990, you could still run it bare metal on some of today's hardware, or on any hardware without too much hassle in a VM. Hardware from 30 years ago running in a cupboard probably has a 50/50 chance of still being alive today, and if you had set up 2 backup machines at the time, you'd probably have something working now even with nobody touching it for 30 years, sans the occasional office move.

<comment><USER9> > IPv4 no longer exists

I hope you're right, but i'm not entirely convinced. IPv4 has proven to very resilient.

A survey in Denmark of pretty much all ISPs reveals that most, if not all, of the large ISPs have absolutely no plans for migrating to IPv6. Not as "not right now", but as "no plans at all". Some of them have plans for migrating business customers, but no plans for residential.

We'll end up with companies running IPv6 and the rest of us stuck on an IPv4 network with a 4to6 gateway.

[https://ipv6-adresse.dk/](https://ipv6-adresse.dk/)

<comment><USER10> What actually is a 4to6 gateway? For example, how would an IPv4 client connect to a 128-bit address like 2606:4700:20::6819:6c0d?

<comment><USER11> I can imagine a weird contraption of a custom DNS server that tracks client requests, returns unique private IPv4 addresses and simultaneously tells to some NAT-PT engine that this source IPv4 address talking to that destination IPv4 address needs to be translated to that IPv6 address.

I can imagine this to be extremely fragile and break whenever an IP address is looked up using any different manner than plain DNS (e.g. by having IP in API responses, or just using DoH). Yet, I can imagine someone's probably already working on this abomination.

<comment><USER12> Just return the same IP for everything and check the Host header or SNI name to know where to forward requests to

It'll work fine for web traffic.

</comment></comment></comment></comment></comment><comment><USER13> While there are reasons for concern, I don't really blame Philips (Signify) for this. They released the v1 hub quite early in the smart home space. It wasn't compatible with Apple Homekit features when they were released due to hardware limitations for reasons they presumably couldn't have predicted (unless they made it a more capable and expensive device in the hopes it would support unknown requirements). They made all v1 owners an offer to get a new hub "free" with a colour changing bulb, though it's not good value if you don't want the colour changing bulb or find it on sale and don't care about the hub. The old hub will continue to work, just not remotely. After eight years, I think it's a responsible and fair response within the parameters of consumer gear. The only way it could be better would be if the hub weren't required at all, or it was more easily interoperable with other controllers, but from the start that would have meant a more complicated experience.

I was an early adopter of Hue, even though it's kind of expensive I enjoy the capability to change the colour and mood of room lighting. $400 worth of lighting hardware for a house over 15 years is less than the comparable effect of painting a single room. From the start it has good support for local-only implementations with good open source libraries.

<comment><USER14> There protocols are well documented and there's plenty of open source configurations based on raspberry pi to run it.

</comment></comment><comment><USER15> So, Philips Hue users need a new $60 bridge after 8 years?

That actually seems reasonable to me. 8 years is longer support than most other devices.

<comment><USER16> If you bought a hammer 8 years ago and the hammer company had a way to "deactivate" certain uses of the hammer so it only worked in a few situations, would you say "8 years is long enough for a hammer, it's perfectly reasonable they force you to buy a new hammer in order for it to work properly." ?

Philips has the resources to keep this up and running.

<comment><USER17> A Hue Bridge is not like a hammer. Your analogy is cute and appealing, but not actually analogous (the biggest problem with analogies...)

> Philips has the resources to keep this up and running.

See how your analogy doesn't work? A manufacturer of a hammer doesn't have to continually expend resources to keep your hammer operating, secure, and compatible with other devices. Because it's just a hammer.

<comment><USER18> That's not right. You've just based your assertion with a faulty assumption that a bulb has to be smart - sure the analogy breaks down. _But_ , the parent is making an analogy about a "dumb" bulb - both hammer and bulb are tools. Hammer is used to hit nails and a bulb is used to illuminate dark spaces.

A manufacturer of "dumb" bulbs doesn't have to continually expend resources to keep your bulb operating, secure, and compatible with other devices - <USER2> by the virtue that the bulb isn't a smart bulb.

To fail your analogy criteria, the bulb just have to be a "dumb" one or the hammer can be a smart-hammer (you can concieve that for the sake of a thought exercise).

<comment><USER17> What? I never said anything about bulbs. A Hue Bridge is not a bulb at all. And "dumb" bulbs still exist, you can buy them, most people aren't really complaining when they don't last forever, and frankly they've got nothing at all to do with my comment or the one I was replying to.

</comment></comment></comment></comment></comment><comment><USER19> The world could seriously use some legislation for hardware devices tied to online (dis)services.

Maybe if you can't guarantee that your service stays alive for the lifespan of your hardware product, your product shouldn't have existed in the first place.

<comment><USER20> Or you'd find manufacturers finding ways to reduce the lifespan of the hardware product...

</comment></comment><comment><USER21> This is exactly the reason why the Twitter account "internet of shit" was created. Yes I know it's vulgar.

[https://twitter.com/internetofshit?lang=en](https://twitter.com/internetofshit?lang=en)

But it's worth scrolling through the previous posts by that account to see a myriad of similar "your expensive internet-dependent thing is now useless" scenarios.

<comment><USER22> [REDACTED]

Agree with child comment.

<comment><USER23> Ads in a product you pay for and ads in a Twitter account you _don 't_ pay for are hardly comparable.

</comment></comment></comment><comment><USER24> AFAIK the bulbs are compatible with v1 and v2 hubs, so the bulbs do not need to be replaced. The v1 hubs will continue to work across a local area network. Philips offered a heavily discounted upgrade for v1 hub users to get a new v2 hub.

However, I still think they should support the v1 hubs for the lifespan of a typical bulb (15 years), at minimum.

<comment><USER25> Yea, as long as it works locally and they don't pull the old app .. still it's shitty they're trying to push people to buy new shit they don't need. It's just creating waste to increase sales. The attempt to grow without responsibility really needs to die. Consumerism with the goal of more consumerism is a cancer.

<comment><USER26> While it's tempting to blame this on Philips doing this to increase sales, I think it's just as plausible that they just don't want to spend resources on maintaining the infrastructure required for the v1 bridges anymore. The v1 was _very_ early in the market, and doesn't even have the horsepower to support HomeKit etc.

This is also a more likely explanation if you consider that Philips offered _heavily_ discounted v2 bridges to v1 bridge owners. It's probable that it's cheaper to Philips to sell v2 upgrades to customers at or below cost than it is to maintain support for the v1 bridge.

Having said that, it sucks for v1 owners that they have a product that's going to lose features unless they upgrade. I do have a few Hue bulbs (with a v2 bridge), but I have everything set up through openHAB, with remote access going through a server I control. This way I don't have to rely on anyone but my VPS provider to keep all of it functional. Unfortunately this route is out of most people's technical know-how. And I certainly sympathize with people who could do this, but would rather use an off-the-shelf product that just works.

</comment></comment></comment><comment><USER27> This forced obsolescence is beginning to get out of hand.

I completely understand that running the online portion of this costs money, but that needs factoring in to the business model from the start. I imagine that they didn't think about this when the product first launched in 2012.

I do wonder if a u-turn (similar to the one Sonos has just done) will follow after bad media coverage.

<comment><USER28> Or maybe they factored in 8 years worth of service?

<comment><USER29> They market their bulbs as having a 15 year life span.

<comment><USER30> The bridge will still work from your private network and one can still control the lights with the app.

All that's being disabled is the external control.

<comment><USER31> ...which all the digital assistants like Google Home or Alexa use, so this breaks voice commands for those. For most people, that's the main reason to have smart lights.

<comment><USER32> The V1 bridge does not require any outside access from an Echo device -- it communicates directly with the bridge over the local network. With V2 it requires a skill, a Hue account, and access from the internet to the bridge.

<comment><USER33> Are you sure it requires access from the internet to the bridge for V2? I think it may only require that the bridge can access the internet.

I have a V2 with "Out of home control" set to disabled and it works fine with my Echo Dot and with the Amazon Alexa apps on my phone and iPad.

My guess is that the bridge sends status information, including the bridge's IP address, to the Hue site, and the Echo can retrieve that information in order to find the IP address to send commands to.

<comment><USER32> You're probably right. I was trying to say that the v2 bridge requires some sort of cloud service to function with an echo when the v1 did not.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER34> I don't get the reaction here.

The __online __service will be shut down but the bulbs will continue to be locally controllable and Philips is releasing a dedicated app to interact with the v1 bridge.

Is it really such a huge deal that you can't access your bulbs over the internet? What's the use-case for this? Are you controlling your lights while you're not home? Do you not have access to the network the bulbs are connected to when you're at home?

I have Hue installed and this just seems like a non-issue to me.

<comment><USER35> Thid means you can't use Google assistant or Alexa anymore.

<comment><USER34> I concur with the other commenter. I think it's a flaw in Google Assistant/Alexa if they're solely able to function using the online service.

The bridge provides a well-documented and stable local API which these assistant devices would be able to use as long as they're on the same network.

</comment></comment></comment><comment><USER36> I need to buy a new TV, and I'm desperately looking for a "dumb" one. I just need a HDMI input and that's it.

<comment><USER37> Isn't that what a computer screen is?

<comment><USER38> Sure, but where can you find a 130cm monitor?

<comment><USER39> I think they are called "commercial displays". You can see them showing ads in shops and etc.

<comment><USER40> They're much more expensive than a TV though.

</comment></comment></comment></comment></comment><comment><USER41> Stop buying smart home shit.

People warned of exactly this when they started.

<comment><USER42> ...and if you do, make sure to buy things that are offline first.

<comment><USER43> Like Philips Hue v1? :)

Well, "local net" first, it originally had no "cloud" support.

</comment></comment></comment><comment><USER44> Do people use these things online ?

I treat mine as regular bulbs that can be controlled via phone.

<comment><USER45> Some people feel comfortable giving Alexa or Google Home access to their household devices and climate control systems; these rely on internet access.

<comment><USER32> That's not entirely true for the v1 bridge. The echo needs internet access, of course, to understand the command but the actual control of a v1 bridge is done on the local network.

This changed with the v2 bridge.

</comment></comment></comment><comment><USER46> I have about 60 hue devices. Its useful enough to me that i would just buy the bridge if I had to. In fact I WANT them to release a new bridge that supports even more devices.

If you ask why - first is I am very sensitive to bad lighting as it seems to be a cause of migraines, Hue has amazing quality. Second I like the automations, not just turning on and off at the right time but also changing colour temperature. Having motion sensors so walking around triggers lights turning on is something that I got really used to.

</comment><comment><USER47> I got hue bulbs and a 3rd party zwave/zigbee USB stick, hue works really well with it via Node-RED and Home Assistant :) I understand that for most users hue bridge seemed like the easiest way to connect but hopefully they will find that it's not that difficult to connect them via other means.

Comparing TP Link (wifi connected) bulb with Hue - the former reacts a lot quicker than tp link after boot (if you are using the normal switch).

</comment><comment><USER48> For the most part, at least we don't have to worry about forgotten, rogue IoT devices. The overriding mission has been to connect it to shitty online services. Watch these companies go out of business or deprecate APIs.

This is very dramatic, but imagine something like this:

[https://www.youtube.com/watch?v=pyMNIFZTQkg](https://www.youtube.com/watch?v=pyMNIFZTQkg)

</comment><comment><USER49> I'll have to check whether or not this'll affect my grandparents' lights. Probably not the absolute end of the world (90% of their usage is "Alexa, (back/front) porch (on/off)"), but I know they do like to control the porch light with the app (it's on a schedule, too).

</comment><comment><USER50> The Hue internet stuff was never useful to me, so even my v2 hub is only used on my local network or by HomeKit. I don't blame them for EOLing it, but it's super nice of them to only take down the v1 APIs and not kill the entire product.

</comment><comment><USER31> Well - they've done a pretty good job of ensuring that if I get smart lights again, I'm definitely not buying Philips.

This change breaks all the digital assistant integrations ("Hey Google, turn on the lights"), which is pretty much the only reason to have smart lights in the first place. If you can't use voice commands, you might as well just use the wall switches. Who wants to pull out their phone and switch the lights on and off with an app?

<comment><USER51> Is there a viable alternative? The website and app are pretty terrible. I assume it's because they have no real competition?

<comment><USER52> There are many, many apps for Hue lights.

The one I use most is Hue Pro by Prismatic LLC. I like its highly customizable widgets.

[https://play.google.com/store/apps/details?id=com.benchevoor...](https://play.google.com/store/apps/details?id=com.benchevoor.huepro&hl=en_US)

</comment></comment></comment><comment> bmo-at This is abominable, there's literally no reason other than "It costs money to maintain this, and we'd rather make money selling new stuff than support what we already made". I have a v2 bridge, but back when I bought it about 3 1/2 years back, I payed a lot of money for it. It's not an expensive product to manufacture, so I expected that money to go towards supporting it long term. So much for that.

<comment><USER53> You paid a lot of money for the bridge? It comes with the starter packs? I know a few people with these systems that have v2 bridges piled up at home as it was cheaper to get the starter kits and a bonus bridge than it was to buy the bulbs individually.

<comment><USER54> I personally piled some v2 bridges in the trash for this same reason. It feels vaguely like shucking external hard drives. The garbage piles up higher.

</comment></comment></comment><comment><USER55> When I moved my Philips Hue bridge got damaged. Turns out there is no way (and I tried) to get your lightbulbs to reset and attach to a new bridge. Not very happy with Philips Hue, wish there was a better option out there.

<comment><USER56> My original bridge recently bricked (hours of wireshark logs led me to believe it boot loops every 17 seconds) and I was able to associate my bulbs with a new bridge easily.

Steps are as follows:

Turn the bulb on for three seconds and then off for three seconds, repeat a few times, then turn it on and it should blink. Turn it off, start the pairing/search process and then turn the bulb back on.

It helps to use a lamp/light switch if you have them somewhere that requires plugging/unplugging to turn off.

</comment></comment><comment> wh-uws So here is my frustration with the hue service... The uptime is terrible.

Outages have happened weekly and there isn't even a place I can see statuses...

There are many night where I want to cut my lights off with the app and I just can't. No explanation just no connection from their application to their service..

There have been so many times I've had to use the api manually to do this

Hopefully this new bridge addresses this issue.

<comment><USER57> Shutting off the lights should be a local operation, you don't need to connect to their server to do it.</comment></comment>


The Prescient Joel on Software - <AUTHOR> https://medium.com/@firasd/things-i-read-on-joel-on-software-that-came-true-cd201c03cf58 <comment><USER2> He is one of my favorite writers. Cash flow is something that is super important in every business. He talks about cash flow in a few of his posts.

I wish in the business economics class that I took at University the professor came in and talk about cash flow every other week. Because running out of cash is the worst. Trader Joe's doesn't really care that I have a million plus in receivables, they are unhappy because my debit card got declined.</comment>


Ask HN: What news sources do you trust? - <AUTHOR> <comment><USER2> None, although there is a difference in the levels of my disbelief. I always try to check multiple sources and if it is possible multiple languages too. I do think many journalists, particularly in online news, let themselves be inspired by each other or just copy press releases from large agencies. Not their fault, it is mostly because of economic pressure, but this is the current reality.

But even the news sources I trust most are prone to errors. We also have a lot more opinion pieces. I like to read them too, but along many papers you can see a lot of uniformity, even if the authors at least try to hide it in subtext. That can undermine trust in news publications because I believe this to have an influence on general reporting.

</comment><comment><USER3> I trust most of our high-quality mainstream news as well as our national broadcasting company, but I'm Danish, so that probably doesn't help HN much.

As far as more international news I trust the guardian, Dee spiegel, the New York Times and the BBC, as well as the national news stations of Norway and Sweden.

</comment><comment><USER4> For me, the short answer is "not one above another". If you can read multiple languages, getting a wide(r) view of news from papers is really valuable.

Also, reading around, digging deeper and looking at the same story from, say, your local news org, a national news org and something like Al-Jazeera is really informative.

</comment><comment><USER5> I do not trust any news source. I take a quick broad view from different news content providers. From social media and the usual big press organisations, TV and radio which gives me a general view. If something interests my curiosity, I then dig deeper into these sources in an attempt to find the vein of truth.

</comment><comment><USER6> Wall Street Journal, Bloomberg, New York Times

</comment><comment><USER7> # My Shortlist of News sources

## websites: ##

### <[https://projectcensored.org/>](https://projectcensored.org/>) ###

### <[https://consortiumnews.com>](https://consortiumnews.com>) ###

### <[https://www.truthdig.com/>](https://www.truthdig.com/>) ###

### <[https://whowhatwhy.org>](https://whowhatwhy.org>) ###

### <[http://accuracy.org/>](http://accuracy.org/>) ###

### <[https://therealnews.com/>](https://therealnews.com/>) ###

### <[https://www.freelists.org/feed/wikispooks>](https://www.freelists.org/feed/wikispooks>) ###

### <[http://www.sourcewatch.org/>](http://www.sourcewatch.org/>) ###

### <[https://celdf.org/>](https://celdf.org/>) ###

### <[https://independentpoliticalreport.com/>](https://independentpoliticalreport.com/>) ###

### <[http://vdlf.org/>](http://vdlf.org/>) ###

### <[http://www.wisconsinlaborhistory.org/>](http://www.wisconsinlaborhistory.org/>) ###

### <[http://wisdomwisconsin.org/>](http://wisdomwisconsin.org/>) ###

### <[https://www.americanswhotellthetruth.org/>](https://www.americanswhotellthetruth.org/>) ###

## Authors/Experts

### [Peter Martin Phillips Intro](#suxiy_Peter_Martin_Phillips_Intro__O072ObioO072O)

### [Robert Parry Intro](#lxxmo_Robert_Parry_Intro)

### [Peter Dale Scott intro](#fnmbt_Peter_Dale_Scott_intro)

### [William K. Black Intro](#ggvqj_William_K._Black)

### [Ray McGovern Intro](#zbhej_Ray_McGovern)

### [Seymour M Hersh](#pbbyq_Seymour_M_Hersh)

### [William F Pepper intro](#pfkpb_William_F_Pepper_intro)

### [Joe Lauria Intro](#mdqgl_Joe_lauria_Intro)

### [Thomas Linsey Intro](#bztbi_Thomas_Linsey_Intro)

### [Stephen F Cohen Intro ](#kknsh_Stephen_F_Cohen_Intro)

### [John Kiriakou intro](#ekysw_John_Kiriakou_intro)

### [Lance deHaven-Smith intro](#ngnle_Lance_deHaven-Smith_intro)

### [Micky Huff intro ](#yjpnt_Micky_Huff)

### [Kathy Kelly intro](#owwrm_Kathy_Kelly_intro)

### [Eva Bartlett intro](#ivtdj_Eva_Bartlett_intro)

### [Michel Chossudovsky Intro](#ufcfy_Michel_Chossudovsky_Intro)

### [Vanessa Beely Intro](#nemlb_Vanessa_Beely)

### [MMT Economist L. Randall Wray intro](#qqvmd_L._Randall_Wray)

### [Michael Hudson Intro](#onyri_Michael_Hudson)

### [Steve Lendman Intro](#ienhv_Steve_Lendman_Intro)

### [William Binney Intro](#atzha_William_Binney)

### [Alison Weir intro](#hpcjo_Alison_Weir_intro)

### [Margaret Flowers intro ](#rjmwo_Margaret_Flowers_intro_)

### [Andrei Raevsky "the saker" intro](#fkrsw_Andrei_Raevsky_AdqtAthe_sakerAdqtA_intro)

### [Ellen Brown Intro](#scdrg_Ellen_Brown)

### [Dave Winer Intro](#jkcjh_Dave_Winer_Intro)

### [Dave Lindorff intro](#bscjj_Dave_Lindorff_intro)

### [Eric Zuesse Intro](#mgcng_Eric_Zuesse)

### [Abby Martin Intro](#vlnia_Abby_Martin_Intro)

### [Gareth Porter intro](#eqbnw_Gareth_Porter_intro)

### [Stephen Gowans intro](#cosim_Stephen_Gowans_intro)

### [David Talbot intro](#cmkyq_David_Talbot_intro)

### [Norman G Finkelstein intro](#vtdqx_Norman_Finkelstein_intro)

</comment><comment><USER8> Most MSM publications simply repeat AP and Reuters press releases without further thought

<comment><USER9> Uhm... no. That's not how national papers work. Yes, they run "wire" stories from AP and Reuters when they don't have a reporter at the scene.</comment></comment>


Startup accelerator Plug and Play Tech Center to open in Vancouver - <AUTHOR> http://www.techvibes.com/blog/us-startup-accelerator-plug-and-play-tech-center-to-open-in-vancouver <comment><AUTHOR> I'd never heard of Plug and Play, even though they seem fairly large. It's clear from their website that they're not quite a seed program like Bootup Labs or Y Combinator, but it's not exactly clear what they are. The feel of their site is pretty corporate and scattershot - does anybody have insight into what these guys are like and how they operate?

<comment><USER2> PnP model is selling services to startups - first office space, then based on your needs it could be hosting, HR etc. They don't take equity and don't have any limits regarding how long you can stay there (because they get paid cash). However the owner (Saeed) also has a fund and does get in on some Series A rounds. There is a lot more about PnP & Saeed Amidi on thefunded.com

<comment><AUTHOR> Ah, that makes much more sense. Thanks a lot Igor.

</comment></comment></comment><comment><USER3> This doesn't bode well for Bootup Labs after their recent fiasco</comment>


A 'Sonic Attack' on Diplomats in Cuba? Some Scientists Doubt It - <AUTHOR> https://www.nytimes.com/2017/10/05/science/cuba-sonic-weapon.html <comment><USER2> Take this as a fairly baseless comment but my reading of analyses around the original incident seemed to be saying that it was closer to microwaves than sonic waves. The side effect of the exposure was that targets had the illusion of hearing sound.

<comment><USER3> I too thought that - especially given that it's (I think) a well known phenomemon: [https://en.wikipedia.org/wiki/Microwave_auditory_effect](https://en.wikipedia.org/wiki/Microwave_auditory_effect)

</comment></comment><comment><USER4> scientists deal in doubt these days and it gets into nytimes. great. scientific method ftw... this comment might be baseless, but it's about as baseless as the article itself. i'd like to see for once again that scientists 'prove' something with maticulous research and evidence. not some educated guesses based on theories yet to be fully proven.

"I'd say it's fairly implausible," <\-- is that the only comment? Why does he say that? Really?

"The data is very slim," said Timothy Leighton <\-- what data? enlighten us?

"If you're talking about a ray-gun rifle knocking out someone with ultrasound they can't hear at a hundred meters — that's not going to happen," said Dr. Leighton. <\-- it's not? Why not? What experiments proved this to be ill effective?

These people have degrees ? Bought at wallmart?

If a mysterious high-tech ultrasound weapon were used, it ought to have been easy to get the evidence while the attack was underway, Dr. Garrett said. Cellphone microphones are often sensitive to ultrasonic sound, he noted, and commonly available iPhone apps could have revealed it. <\--- kind of depends on what frequency you are emitting doesnt it?? cellphone frequencies are within a specific band.. do all ultrasonic frequencies influence these? i doubt it!

as usual with these scientists, no reference to any research or sources is given. Superb!

 _breathe_

edit: somewhat sensible scientist, atleast gives a bit of a broad comment which isn't bad, though it adds nothing of value ofcourse!

"I believe those people got something that hurt them," said Dr. Qin. "But it could be something in the environment." The possibilities include toxins, or bacterial or viral infections, that can damage hearing.

yay science "something did something and it had some effect".

<comment><USER5> > _These people have degrees ? Bought at wallmart?_

The trouble with comments like this is not that you're wrong—there's a chance you're right and really do know better than the people you're criticizing. But when you post like this, you make your comment indistinguishable from random internet detritus. In a way it doesn't matter if you're right, because that would only encourage the internet bullshitters to post more, and lord knows there are 99.9+ of them for every 1 of you.</comment></comment>


A command line tool to manage your ssh connections - <AUTHOR> https://github.com/emre/storm

<comment><USER2> Is it really easier than just editing ~/.ssh/config? In the config, you can use wildcards for groups of servers

        Host *.whatever.net
           IdentityFile ~/.ssh/whatever-key
           ServerAliveInterval 10
           port 1022

and then add specific information and aliases per host

        Host someserver.whatever.net someserver ss
          Hostname someserver.whatever.net
          User spin

        Host otherserver.whatever.net otherserver os
          Hostname otherserver.whatever.net
          User dritf

Plus, since you probably edit it only once in a while, you don't need to remember the syntax and can simply base new additions on existing entries.

<comment><USER3> It's probably not much easier, but the tool is almost certainly less error- prone. I like to see this extended with a GUI, but it's a good start.

<comment><USER4> I doubt it's less error-prone. SSH config files aren't particularly complicated, and if you get it wrong, it's easy enough to fix - just edit the file again.

</comment></comment></comment><comment><USER5> I hate to be snarky but having read through the code this really isn't a big thing. It's a tool for people that can't use .ssh/config.

Manage your SSH like a boss? Perhaps, but only in the pointy-haired can't-read-man-ssh_config boss sense of the word.

For those that don't want to install a script and would prefer to understand the tools they already have try this:

[http://nerderati.com/2011/03/simplify-your-life-with-an- ssh-...](http://nerderati.com/2011/03/simplify-your-life-with-an-ssh-config- file/)

<comment> emre-yilmaz There are a lot of tools like that for years.

like;

\- managing /etc/hosts \- managing crontab

It's just a preference to do it with a command line tool, or just doing it in the config with editor.

<comment><USER5> I don't have a problem with the tool. If it helps people it's doing a good job. My problem is only with the article title overplaying it's utility somewhat.

</comment></comment></comment><comment><USER6> I agree with the comments to just freakin edit your .ssh/config. But, it clearly states "SSH like a boss". The implication I take means "configure ssh for people who don't know how to use an editor, can't read man page, don't know where man pages are, and can't find/don't know about .ssh."

So, not for us. We can move along and be happy someone else is taking care of those people.

<comment><USER4> The people who can't use an editor, read a man page, and don't know about SSH a) probably don't need this and b) would probably have just as hard of a time figuring out how to use this CLI utility as they would learning nano and .ssh/config syntax.

</comment></comment><comment><USER7>
        vim ~/.ssh/config

</comment><comment><USER8> Honest question:

Why is this preferable to using:

vim/emacs/subl/nano ~/.ssh/config ?

<comment><USER9> It is not.

</comment></comment><comment><USER10> I've built a script that creates the config by querying EC2 for servers, this avoids having to pass around server names when new servers are created. Just run the script and every server is added.

</comment><comment><USER11> When I saw the project name, the first thing I thought of was: <https://github.com/nathanmarz/storm>

<comment><USER12> And I was <https://storm.canonical.com/>

</comment></comment><comment><USER13> Very cool. I'd love to actually set this up with some scripts as a way to manage server migrations or new servers

I'm actually working on a web-based gui for managing ssh configs and I'm likely to switch to python and reuse some of this

<comment> emre-yilmaz happy to hear that :)

loading and dumping ssh configs would be tricky. let me know if you need further assistance.

</comment></comment><comment><USER14> What does this add over just editing ~/.ssh/config with $EDITOR?

<comment><USER13> It becomes useful when: You have a large number of items in your ssh config, say 20-100+ and you don't want to jump around in vim. When you want to control teams' ssh configs using scripts. If you have a team of developers that all have this installed, you can now update ssh configs just by having them run an executable or possibly by some sort of job queue. Want to switch to key-based access for an old server, delete a different old server and give devs access to a new server without having to coordinate and answer questions with 20+ people? You now have the ability.

Very nice work

</comment></comment><comment><USER15> In OS X, by pressing Cmd+Shift+K whilst in Terminal.app, you can save SSH, SFTP, FTP and telnet connections. Personally I don't use it but some people might prefer it.

</comment><comment><USER16> I read through the readme and I couldn't figure out how this is an improvement over ssh_config(5), other than adding Yet Another Dependency.

</comment><comment><USER17> If this could make key management significantly easier (e.g. no need to rely on the buggy GNOME keychain app) or make it easier to manage persistent connections (ControlMaster is trivial, but juggling dozens of connections and gracefully terminating/resuming them is not), maybe it would be genuinely useful.

For the time being, though, this just looks like a lightweight editor for ssh_config.

</comment><comment><USER18> The boss wants putty, the user can edit .ssh/config by himself already.

</comment><comment><USER19> more easy to write bash aliases like alias ssh-web="ssh username@host" and you take bash completion support

<comment><USER20> There is bash completion for ssh.

Its included as part of the bash-completion package on most distributions of linux.

Its got extremely good completion support for hostnames

It has the added advantage of also auto-completing for scp.

<comment><USER21> SCP autocomplete is very useful indeed. Especially when using ControlMaster, then autocomplete is almost instantly.

</comment></comment></comment><comment><USER22> I can see this being useful if you have lots of keys and the server kicks you when you try too many of them, but in theory you really shouldn't need more than one key.

<http://www.funtoo.org/wiki/Keychain>

<comment><USER23> slightly exaggerated: by that logic only one password should also be enough.

<comment><USER24> No, that's a little different. The problem with password reuse is that if someone breaks into a site and steals the passwords, or a malicious administrator steals your password, they can reuse it. The public/private key separation of ssh keys means that that is much less of an issue. You can't login to another server with my public key.</comment></comment></comment>