PostgreSQL example of self-contained stored procedures - <AUTHOR> https://sivers.org/pg2 <comment><USER2> I'm the author. Thanks to Ludwig for posting this here.

I've been doing all of my database work like this for 5+ years now, and love it. Many more examples here:

[https://code.sivers.org/db-api/](https://code.sivers.org/db-api/)

It works great when you want to write simple shell scripts, too. They look as simple as this:

[https://github.com/sivers/store/blob/master/getdb- example.rb...](https://github.com/sivers/store/blob/master/getdb- example.rb?ts=2)

People have been asking how I do unit testing. The main thing is to have a fixtures.sql file, which is a dump of data to test against: [https://github.com/sivers/store/blob/master/store/fixtures.s...](https://github.com/sivers/store/blob/master/store/fixtures.sql)

Then in the setup before each unit test, just drop the database schema, and reload it:

[https://github.com/sivers/store/blob/master/test_tools.rb?ts...](https://github.com/sivers/store/blob/master/test_tools.rb?ts=2)

Examples of my API unit tests here:

[https://github.com/sivers/store/blob/master/store/test- api.r...](https://github.com/sivers/store/blob/master/store/test-api.rb?ts=2)

And also testing things like database triggers, and private functions:

[https://github.com/sivers/store/blob/master/store/test- db.rb...](https://github.com/sivers/store/blob/master/store/test-db.rb?ts=2)

Feel free to ask me anything here, or email me: [https://sivers.org/contact](https://sivers.org/contact)

— Derek

<comment><USER3> I read this a few days ago. I was waiting for it to show on HN because I have a few questions.

I want to do the same, but with big databases (the TXID wraparound is a problem every few months). For now, the queries are stored in the code. They rarely evolve.

How do you manage versioning? Queries in code mean you can ensure everything match.

How easily other people interact with that? Not many developers know SQL well. Poor SQL skills can slow down a server for other users.

What did you gain in practice? It is nice, like CI/CD or version control, but I see little gains for something that does not change very often.

Currently, most of the queries are materialized views that can be refreshed separately. It seems simpler to me.

In practice, how is this different from refreshing materialized views?

<comment><USER2> Versioning: sorry I'm not sure what you mean. Same as if you had queries in an ORM and views using the results, you'd need to branch and make changes, then merge the branch together at once. I just do the same. If the database structure changes, I run the ALTER TABLE commands, when switching to that branch.

Other people : I guess like anyone choosing a language, you're excluding those who don't know it. I'm assuming more know SQL than Rust or Elixir or whatever. And more should.

Gain in practice : Two best improvements were:

(1) Having all data and data-logic (which might also be business-logic) in the same place. No worrying that some external code somewhere might have old data/business logic in it. One definitive source. Like Rich Hickey's classic "Simple/Complex Hard/Easy" talk - [https://www.youtube.com/watch?v=rI8tNMsozo0](https://www.youtube.com/watch?v=rI8tNMsozo0) \- I like that this is simple, un-complex. The data and external code don't need to be braided/complected together to work.

(2) The freedom do switch my external code from Ruby to Go or Elixir or whatever, and not have to rewrite all that functionality. It's all just simple API calls.

Sorry I haven't looked into materialized views yet, so I don't know how this compares.

<comment><USER3> Thanks a lot for your reply!

It seems the main gain for your is to move between languages and allow initial iterations/bugfixes without touching the application code.

The database has more maintenance issues (like rolling txids) than the application code. I am not sure I want to add more complexity and potential issues to the database.

FYI, a materialized view is a potentially long or complex query whose results are cached, so you can say 'select * from complex_query_result' to get them, and refresh the complex_query_result whenever you feel like it. You can also update the query that generates complex_query_result.

In practice, MV can give you speed (as you can refresh the MV when you need/want, while keeping the results) and also put the data-logic inside the database (as the MV is defined initially, and can later be updated) if you don't need super fresh results. If you do, use a regular view.

In either case, you can use the view approach when parameters are needed, iff you can reduce you query to where parameter=something on the view. Otherwise, you need to use languages like pl sql.

As the materialized views queries just return the results to be processed, and I have very little extra to do, your approach seems overkill for my use case.

<comment><USER4> Unless it changed very recently be aware that you can't update sql definition of a materialized as easily as you would update a view. There is currently no "CREATE OR REPLACE" option so any dependencie build onto a materialized view can quickly become a real pain (been there). Sometime, it might be easier to stick to the old trick of a table updated by a refresher function (possibly called as a trigger).

<comment><USER5> Dependencies are a general problem, like changing the type of a table that has dependent views. It's a good idea if your database update scripts/migration software can handle something like this. Other databases don't tend to be as strict as Postgres here (I only found out that some rarely-accessed views never quite worked after migrating from Oracle)

I've had good luck with these functions: [https://gist.github.com/mateuszwenus/11187288](https://gist.github.com/mateuszwenus/11187288)

Allows you to save-and-drop dependent views (materialized or regular) and then restore them after your updates.

<comment><USER4> Deeply agree about dependencies being a general problem.

Thanks for the script that look pretty clever #bookmarking. Like particularly the approach of "drop what you saved, no more no less". DROP CASCADE is simpler but can have undetected side effect, if this script fail to backup all dependency, logically you will get an error when attempting to delete target and that rocks.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> One unmentioned reason this is powerful: It avoids concurrency bugs and inconsistencies introduced by write skew, in cases where the application layer (eg. Ruby/Python) makes business logic decisions based on data that has become stale.

These are hardest to detect and avoid in the case where business logic depends on no rows matching (count(*) == 0), eg. meeting room scheduling systems, because there is nothing for a transaction to lock!

Stored procedures can avoid this entirely, even under the weaker transaction isolation levels, by keeping all the logic in the DB and running it atomically. At Zipcar we took this approach to writing the web reservation system in the early 2000s. Later, it allowed us to easily add a telephone reservation system without duplicating business logic.

It worked great back then and it still works great, if you have good ways of managing the tradeoffs (version control, unit testing, etc).

<comment><USER7> Ive worked on several apps that tried this approach and each of them was a mess. I've seen two fundamental problems with building your app on top of stored procs:

* Tooling around sql is generally inferior to what's available for <pick your favorite language>. I've yet to see a company with effective automated tests around their database... it's far more common to have _no_ tests around the database. Even if you're the unicorn that does have all of that figured out, it still tends to be more difficult for your devs to write and test code.

* Most devs are poor to mediocre when it comes to sql. You're either going to have to hire more specifically for sql, or force your devs to do complex work (your business logic) in a toolset that they aren't that good at.

IMO this is a case where a few applications may have significant concurrency issues that warrant the database business logic approach... but for your average app, it's unnecessary and makes life more difficult for your team.

<comment><USER8> This has always struck me as odd, how can _any_ competent developer suck at SQL especially after spending maybe a week or two trying to write logic in it? As "languages" go it can't get any simpler, you're just directly forced to think about data in a model that's extremely close to the data itself. Seems to me that a dev that can't think well in SQL with minimal training is not a good dev at all, and this could actually be a nice filter.

</comment></comment></comment><comment><USER9> I'm curious if anybody has practical experience developing a reasonably trafficked website in a similar manner.

I wrote apps which consisted mostly of oracle stored procedures when I first got out of college, and it was a pretty awful experience, but it was also at a place where the development knowledge was minimal.

I've since been getting closer and closer to writing postgres in this way. My current app (which I architected) sticks close to postgres and uses many of its features like custom types, enums and json, but we don't rely on it for stored procedures at all. Instead, all application logic lives in the go API app.

I've been considering moving some things directly into the database, but I'm nervous about it because the app runs well and I like the data/logic division. Also go seems easier to learn for new developers than SQL, and it's a lot easier to deploy a new app server than it is to reconfigure a database server.

<comment><USER10> Every once in a while I encounter somebody who heavily promotes that way of working. There are a couple of arguments I've heard in favor of it. Often it's a mix of performance, ultimate data integrity, and "simplicity". I just don't buy it.

If performance is so critical, whatever you gain by moving everything to the database is lost by the fact that databases are harder to scale. You may be able to get by with a single instance a little longer, but when eventually you don't anymore, you've now worked yourself in a corner. It's an 80/20 game anyway, so just use an occasional stored procedure when it's really worth it.

For data integrity, I've always found databases not expressive enough. Sanity checks, okay, but you can't capture a non-trivial domain in some custom data types, check constraints and foreign keys. Even if you introduce stored procedures that will be responsible for keeping everything proper, you need to go crazy with permissions to block circumventing those. Might as well build your own API then. (I do find it difficult where to draw the line when it comes to what to enforce in the database still.)

"But you don't need another API! Just use the database as one!" Then I ask how they do testing, and the answer basically is: "We don't make mistakes or we find out about them (in production) soon enough." That pretty much ends the discussion for me. Surely there must be ways to devise a basic testing framework for stored procedures, but why bother? I don't want to spin up a database just to test some logic. Never mind testing, what about refactoring?

From a theoretical point of view, I can see the potential, but practically...? The tooling isn't there, and perhaps that's for a reason. Maybe databases are just not supposed to be used that way. Despite the extra functionality they offer, I treat them mostly as a data _store_.

What am I missing? I would love to be proven wrong.

<comment><USER11> We write most code in backend (go), but we DEFINITELY spin up a new, real SQL database in for every test in our automated test suite. ("CREATE DATABASE" is rather cheap; use a fresh docker DB instance for each suite run, or run it permanently while developing.

Mocking away DB is both an inefficient way to work and lets the tests cover less. I will never write software without running tests against a real DB again.

Our setup totally would let you test anything in stored procedures (although we do not use them much).

<comment><USER12> agree on the mocking the database - I wrote an entire test suite based on mocking the database responses, and then found a ton of live problems caused by the database - backend interaction (things like structs not aligning with the actual return records from functions, input format for arrays of ids being different from the mockup to the actual driver, and hstores).

Now I have a test database, which I create from a version-controlled schema.sql, and each test creates its own fixtures in the test db. Works way better.

</comment></comment></comment></comment><comment><USER13> This is an old pattern (like early 2000s MS SQL app development) and works wonderfully for the majority of applications.

It does become complex and awkward in two case, 1) variable option selection and 2) at a certain "scale" / quantity of inserts/deletes.

Variable option selection

Take for example a search interface of dependent items and item options, like cars. The query for car options for different car models generally returns a variable list of options. Further filtering results based on the variable list of options, when the list of options is all in one table, is most efficient with an "in clause". Trying to represent the "in clause" using functions/stored procedures is a little awkward as there is list construction and deconstruction involved, and sql is not great at list/string parsing.

Number of inserts/deletes

At some point, a successful app will reach a point where it's more efficient to batch insert & delete -- a couple hundred rows. This goes back again to using "in clauses' and the stored procedure approach makes things a bit awkward, as then the store procedure will need to argument parse and check.

Not saying what's done here is bad - it's actually really good for many, many reasons. I'd actually recommend the approach and avoid what I've described above unless it makes the desired functionality hard and complex.

</comment><comment><USER14> This is how I do relational databases in 2019. My database is a self contained module more akin to an rpc api than a database. My code has virtually no database logic in it at all. I don't know but it feels like functional databases could be a thing. We should call Martin Fowler and ask.

<comment><USER15> How is that not how databases are typically used?

<comment><USER16> Returning JSON to a client is relatively recent. The standard for web apps was to get data from the db and generate HTML on the server. A JSON layer would be a useless overhead.

Furthermore about everybody knows how to use an ORM. Not many people can write store procedures. Maybe the question is why is that so. I heard "I know [language], I don't know SQL, so I write queries in [language] " so many times even from people I would have expected to have a much broader knowledge. (That also applies to networking technology, they know HTTP and nothing more.)

By the way the code doesn't address authentication and authorization, those go in the layer between the client and the database.

<comment><USER8> Do you think it's an acceptable excuse for a dev to say they don't know SQL?

<comment><USER16> No, it's not acceptable. Still it's evident that it doesn't prevent getting a good job.

</comment></comment></comment></comment></comment><comment><USER17> Stored procedures can also be a great way to scale out transactional workloads.

In Citus (a sharding extension for Postgres by Microsoft) we recently introduced a stored procedure call delegation feature.

If your tables are distributed by person_id and you have a stored procedure that takes person_id as a parameter, you can run e.g. "SELECT create_distributed_function('lineitem_add', 'person_id')". The procedure calls for a given person_id value will then be fully delegated to the PostgreSQL server that stores the data for that person_id without additional round-trips between statements or distributed planning overhead. It'll "magically" take care of procedures that access data from other servers as well.

I realize we're basically going full circle to PL/Proxy, except in Citus almost everything else (distributed queries, DML, DDL, transactions) works as well.

</comment><comment><USER18> I've been using this pattern recently. Very early stages but I like it so far.

I wrote some boilerplate tools for easily loading schemata and extensions. This is a must have for being able to write isolated tests.

I keep all data definitions in schemata, which can be managed by standard migration scripts. I keep function definitions in extensions, which do not create any data stores but expose functions with well defined interfaces for querying the underlying data. I rely on standard Postgres extension loading to manage migrations.

I really like this pattern, but there is a degree of unapproachability to it. It takes a lot of effort to make sure tests work well - but it's not so bad. Since your DB functions do everything, the app code is just a shell around those functions (few lines of code to call each function), so by testing those functions you are exercising their Postgres counterparts.

With tools like postgraphile and Postgrest available, this is becoming a more appealing option. What we need is more tooling for managing deployment, installation, migration, verification of and communication with the stored procedures from within application code. Combined with Postgres PL libraries like plv8, it should be possible to write JavaScript code within your application toolchain that you can test locally, but deploy to run in Postgres context.

</comment><comment><USER19> I've been working on some projects and offloading as much as I can to the database. [https://github.com/jimktrains/jskerp](https://github.com/jimktrains/jskerp) and [https://github.com/jimktrains/jskplan](https://github.com/jimktrains/jskplan) being the two I'd like to get further along with.

Working in the DB like this is both very nice and ... very odd? It doesn't feel like most development environments and feels like going back to C or pre- object Ada (I believe Pl/SQL is based on Ada syntax-wise) or Pascal where you're writing lots of global functions that operate on structs.

Once I gain a little more experience developing like this, I'd love to think about that and see if there'd be a way to build a language that feels more "modern" and that can be transpiled to SQL (including building diffs from a current database).

</comment><comment><USER20> How would somebody implement this for a team with versioning, source code view, and deployment?

<comment><USER21> One can create the stored procedure and store it in an .sql file which can be version controlled like any piece of code. These can then be deployed in a number of ways.

</comment></comment><comment><USER22> This kind of approach can be good for getting data into the database, especially for non-trivial updates, but is not good for getting data out. The problem is if you want things like custom group-bys, sorts, joins, windowing, etc, you end up reinventing a lot of concepts, or copy+pasting procedures with slight variations. It basically takes SQL's biggest issue, query composability, and makes it even worse than it already is.

<comment><USER23> > The problem is if you want things like custom group-bys, sorts, joins, > windowing, etc, you end up reinventing a lot of concepts, or copy+pasting > procedures with slight variations.

I could see how you could get that impression if you've worked on a project with poorly planned functions, but our experience has actually been the opposite of that. On the contrary, using PostgreSQL functions has allowed our company to be more consistent and declarative with our return data and has helped us eliminate repetitive SQL code. Particularly so when used in conjunction with our RESTful APIs.

Don't forget that in Postgres you can define custom composite return types (i.e., a return type that includes another return type). You can have a Postgres function that returns nested objects like this (I'm using JSON for clarity):

[ "name":"Bob" ,"age":13 ,"address":"123 Main St" ,"cars":[ { "make":"Toyota" "model":"Camry" "license":"NF98549" }, { "make":"Toyota" "model":"Corolla" "license":"NF5649" }, ] ]

The ability to enforce that kind of return type for a given function is incredibly helpful

> It basically takes SQL's biggest issue, query composability, and makes it > even worse than it already is.

I think that the bigger problems are ORMs like SQL Alchemy. Where it not only introduces a new layer of abstraction but also empowers engineers to request data from the database in a completely ad hoc "unregulated" manner. In large projects without a strong lead or code review process, it can quickly turn into a spaghetti mess that seriously complicates database re-factors.

When you use functions, you have clearly defined inputs and outputs, better re-usability and much more consistent interactions between the application layer and database layer.

</comment></comment><comment><USER24> I'm reminded of the fully-functional HTTP web server (!!) implemented in pure PostgreSQL for the PlaidCTF competition this year: [https://cr0wn.uk/2019/plaid-triggered/](https://cr0wn.uk/2019/plaid- triggered/)

It does everything in SQL - header parsing, HTTP routing, and even includes a micro templating engine for generating pages.

</comment><comment><USER25> As neat as this is, I'm not sure I'd recommend this - I'm not sure what the plan would be when it came to scaling.

<comment><USER26> Tell us about your scaling problem. Do you really have a scaling problem?

<comment><USER25> Ok, where does this go when it needs to grow beyond a single machine? Is it time to set up replication? Partitioning?

<comment><USER26> How many orgs do you know that need to grow beyond a single machine let alone an indie developer? This post was from an indie developer not some big corp engineering blog. I don't know what you mean by partitioning, I'm assuming sharding and not partition/splitting of tables, because this approach is not mutually exclusive to that. MySQL and PostgreSQL can scale up very vertical if designed well. 99.99% or even more never need to scale horizontally. Nevertheless, this can be scaled horizontally carefully a bit. You grow your replicas. Your main DB will be your transactional DB. All procedures that are doing inserts/updates/deletes and select will call that DB. All non transactional SELECTS will call the read only replicas and treat those as your analytical. You can easily have something like one main DB, 3-5 read only DB. Add caching, Add queues and you can have a system that can serve 1+ million users daily.

</comment></comment></comment></comment><comment><USER27> Why are stored procs still used? My experience with the black hole (or really I should say not in version control) pushed me away from them.

<comment><USER28> Why not put them in version control, and have your deployment process pull them out of the repo and apply them to the database?

<comment><USER29> It's a bit more complicated than just "upload all my stored procedures" in practice. I think we need a version control / deployment system that is designed for databases to make this work.

We want it to regard the database as the source of truth, and understand that while you can blow away a development database, you can't do that to prod.

We want it to be able to track which clients are using which stored procedures so it can prohibit dropping stored procedures that are in use. Ideally, when those clients upgrade to newer versions, it's then able to drop them automatically.

Stored procedures can bind to tables, views, types, etc. so it needs to be able to recommend migration plans.

<comment><USER30> I don't get it. You have a source file. It has your store procedures and what not. You deploy it. You have the server startup load it. Done.

What's the problem?

Well, you might complain that some schema changes are hard to make this way, and that's true, but for stored procedures it's straightforward, and even for other things you can manage and make the update atomic (though it'd be nicer to have better SQL language support for schema changes).

As with everything, you need to mind backwards compatibility. This is true for C, C++, Rust, Java, and SQL/PlPgSQL. There's nothing special about this case.

<comment><USER29> > You have the server startup load it.

We have to take down a production database to do this?

Or do you mean the app server is going to do it, in which case how do you handle different app servers with different versions of the stored procedure? Especially if we're doing phased deployments?

<comment><USER30> No, you can load it at any time. Just write (and test) SQL that is safe to load for upgrading a schema.

</comment></comment></comment></comment></comment></comment><comment><USER31> postgrest for those who dont know.</comment>


A transparent solar cell that could make every window and screen a power source - <AUTHOR> http://mobile.extremetech.com/latest/221895-a-fully-transparent-solar-cell-that-could-make-every-window-and-screen-a-power-source?origref=http:%2F%2Fm.facebook.com

<comment><USER2> This is a novel idea (as they note, transparent + power generation seem oxymoronic), but my impression is not tha we're hard-pressed for available surfaces for small-scale photovoltaic installations. Walls of my house. Roof of my house.

The issue is cost of producting, installing, and maintaining a small-scale installation v. the output.

I don't know. Maybe giant glass skyscrapers will find this of value--blocking UV is a desirable side-effect as well. But predictions of "maybe as high as 5% efficiency" make me skeptical of it being particularly revolutionary.</comment>


Yahoo Announces Resignation of Jerry Yang   - <AUTHOR> http://www.businesswire.com/news/home/20120117006946/en/Yahoo%21-Announces-Resignation-Jerry-Yang <comment><USER2> Maybe I'm in the minority here, but I don't think "fixing" Yahoo ought to be as difficult as people make it seem. It's still a well regarded brand, and many millions rely on it for email and as a homepage. It's finance section remains extremely popular. They purchased Sportacular, the app I use to keep track of games. Theyve just been very poorly managed. They acquired companies like delicious and Flickr, one they let wilted and the other they never really integrated into their platform- Flickr just feels like a freestanding entity. They should cut out the garbage that doesnt get many users and should focus on their prized assets. They should push ahead in developing unique content for their viewers. It may be too late to get into the mobile OS game, but TV is still pretty wide open and Yahoo can really do something here, using their existing assets and by further developing or partnering with content providers. I'm hopeful.

<comment><USER3> _Maybe I'm in the minority here, but I don't think "fixing" Yahoo ought to be as difficult as people make it seem._

I worked for a semi-dysfunctional semiconductor company and so I think I have some perspective on what it takes to "fix" a company like Yahoo.

I think the biggest reason a company becomes like Yahoo has less to do with senior management and more to do with the fact that the company is filled with low to mediocre quality middle managers and employees. Mediocre managers aren't very good at their job, so it seems like they make up by playing politics. Once politics is rampant, what gets done is not what works the best, but what helps you or your team get ahead in the political game. At this point you start bleeding talent because good people prefer not to work in an irrational workplace. You also lose the focus and initiative you need to keep a successful product successful.

The worst part is that there's nothing you can really do to fix this. You can try to fire the bottom 10%, but if you only have a problem with the bottom 10%, you're not yahoo. You probably need to fire the bottom 50%, but then you wouldn't have enough personnel to keep all your assets going AND some of that 50% would also be good employees who lost out in the last edition the political olympic games.

Any well-intentioned change in process or product focus by top-management will also inevitable morph into something completely different thanks to your low- quality middle managers who won't understand what you're trying to do, but will understand that they need to step up the politics to keep their jobs.

I guess the point of my rant is that a big company is like an emergent system and you can't really fix a dysfunctional emergent system by changing a small number of things that are part of that system.

<comment><USER4> "Swat Teams" of vetted talent to handle the most prized assets and initiatives. Let the cruft keep up day to day, apply proven talent to the most important initiatives piece by piece. ie. Apple and the iMac, then iPod, iBook, iWorks, Final Cut etc etc.

<comment><USER5> I actually work in exactly this type of swat team. We were all hired at well above standard payrates at my large company to build the next generation product. The response from the existing teams was immediate - they saw us as a threat, and started doing everything they could to make our project fail. In the end they succeeded in gimping the product by simply giving us interfaces that just couldn't do what a good product needed. The swat team was dragged into mediocrity. Now many of those rather expensive hires are actively looking to move elsewhere.

Moral of the story - building a star team in an existing company is a good way of building resentment about that team and is unlikely to breed success.

<comment><USER6> Why didn't they give you the power to demand things from other teams, lest they be fired?

<comment><USER7> You can demand a functional API but you cannot demand a reliable service. That is what they've been unable to provide in the first place.

</comment></comment></comment></comment></comment></comment><comment><USER8> Yahoo is usually talked about as if it's a joke or a failure. According to a cursory check (ahoy - I'm no finance king so I could be reading this wrong) it's worth $19 _billion_. If I could fail half as well, I'd be pretty happy.

Honest question: Am I missing something really obvious? Is Yahoo really falling apart (slowly I guess as the same has been said for the past decade)? Or is it a case of not fulfilling potential?

<comment><USER9> Yahoo is way under valued. Yahoo was considering selling its stakes in Yahoo Japan and Alibaba Group for $17 billion. Yahoo's current market cap is $19 billion PLUS $2 billion cash. Does that somehow make the value of its U.S. assets negative?

<comment><USER10> What value that Yahoo chooses to assign to its own divisions is kind of besides the point.

<comment><USER11> Those are not divisions, they are shares in entirely separate, publicly traded companies. The valuation is market valuation -- not a number made up by Yahoo.

</comment></comment></comment></comment><comment><USER12> I'd be interested to learn about _his_ views and opinions on Yahoo during these past 15+ years. From the various things I've read about him, he seems like he was just a nerd at heart who wasn't interested in the entire business side of Yahoo, and when Yahoo started exploding, he had that "Allen/Woz" mentality of missing the "good old days". I heard about the stories (fair or not) of him spending more time on the golf course than the board room. I also have to think back a few years to when he said "No" to Microsoft's offer for acquisition, a very foolish move looking back.

I guess what I'm really saying is I'd like to read his biography when it comes out.

<comment><USER13> <quote>when he said "No" to Microsoft's offer for acquisition, a very foolish move looking back.</quote>

name companies acquired by Microsoft when microsoft already had competing products, which ended up well for both parties.

honest question. I have to believe there are a couple. and i'd like to know about.

<comment><USER12> His job was to do what was best for shareholders, not his employees and definitely not himself. Tough to argue that turning down $33 for the current $15.50 was best for shareholders.

<comment><USER6> >His job was to do what was best for shareholders

Says who?

<comment><USER14> The law mostly. Otherwise ownership of companies would be mostly pointless, similar to that of gambling (in that your fate would be mostly random, more so then it currently is).

<http://en.wikipedia.org/wiki/Board_of_directors#Duties>

<comment><USER11> Your statement about the law is for the most part not true. There's a much more in-depth discussion of this at this older HN posting: <http://news.ycombinator.com/item?id=3227980>

I agree with you that yahoo should have sold to microsoft, by the way. But the legal duty to maximize value bit is just not accurate.

</comment></comment></comment></comment></comment></comment><comment><USER15> 17 years is a really long time at any company. Jerry has done an amazing job building Yahoo! from a startup to dominate player in the tech industry and has created 13,600 jobs.

Yahoo! already up 3.24% in after hours trading... so the market liked the decision.

Its a choice between shareholder value and wanting to hold onto the core culture of the company. An interesting discussion on the Microsoft offer: [http://www.quora.com/Yahoo/Why-did-Jerry-Yang-pass-on-the- Mi...](http://www.quora.com/Yahoo/Why-did-Jerry-Yang-pass-on-the-Microsoft- offer)

<comment><USER16> standard disclaimer: afterhours trading is very thin liquidity, so a small amount of trading can move the stock price significantly without meaning much. tomorrow's opening price is the first real indicator of what "the market" thinks.

</comment></comment><comment><USER17> Yahoo is lost as a brand.

My children don't know what Yahoo is.

It is one of the million insipid content destinations on the web.

<comment><USER18> Your children also probably don't know what Petrochina is but like Yahoo that doesn't make them an unprofitable company. The nice thing about no one knowing who you are is that 22 year old college geeks don't get the idea to 'disrupt' your industry and instead focus on 'disrupting' a more well known brand like Facebook.

I'd suggest educating your children as to how to make money instead of brand recognition.

<comment><USER19> You can't disrupt Yahoo as a random 22 year old geek starting a company. The revenue streams and traffic base of Yahoo is extremely diverse.

Unless you plan to simultaneously disrupt web email, search, financial portals, sports, news, generalized all purpose portals, and on and on.

<comment><USER20> Yeah but in this case the diversity is a weakness. You can't replace Yahoo! because they don't do one thing really well, they do a bunch of things mediocrely well. What is the Yahoo! brand? What do they do anymore? No one really knows, even though they do a ton, so how could you even aim to replace them at all? At best you could aim to replace Yahoo mail, and that seems like a very reasonable (though still ambitious) startup goal.

</comment></comment></comment></comment><comment><USER21> Apparently this thread is full of people who are better at being CEO of a multi-billion dollar company than anyone at Yahoo in the last several years.

</comment><comment><USER22> There are also sources reporting that four more board members may be following him: Roy Bostock, Arthur Kern, Vyomesh Joshi and Gary Wilson. [http://allthingsd.com/20120117/sources-four-more-board- membe...](http://allthingsd.com/20120117/sources-four-more-board-members-will- be-following-yang-out-the-door/?mod=tweet)

Still rumor at this point, but the Wall Street Journal has a pretty good track record overall.

</comment><comment><USER23> Yahoo!'s new spinoff, HortonWorks, can become a billion dollar Hadoop company down the line if they carefully navigate around Cloudera and MapR. Not sure how/if that affects Yahoo shareholders.

</comment><comment><USER24> I don't believe Yang did write that since he never (ever) used any capital letters in any of his communication.

</comment><comment><USER25> Q. When does Microsoft announce the acquisition?

<comment><USER26> A. After HTC has sold enough Android phones

<comment><USER27> Because if they had to rely on WP7 sales, the answer would be "never"

</comment></comment></comment><comment><USER28> Does it mean Yahoo is on the verge of being brought?

</comment><comment><USER29> Wonder if Yahoo! will get real shitty. Then, 10 years from now, Yang will come back, save the company and make it the most tech profitable company ever. Better buy some stock.

:-)

<comment><USER13> not that far fetched. think you being mostly downvoted for language and emoticon.

this is a /. comment about the case, mentioning jobs "resigned after 9 years. Sold all his stock. Apple III had failed. Mac was fine, but the board wanted an "adult" in charge. Steve returned in 12 years"

<comment><USER29> I'm not angry about downvotes. I know jokes have no place in HN :-)</comment></comment></comment>


Announcing Free and Automated SSL Certs - <AUTHOR> https://blog.heroku.com/announcing-automated-certificate-management <comment><USER2> This is great news, thanks Heroku. This feature sticks well to their "code, we do the rest" philosophy.

I hope the other PaaS will follow.

<comment><USER3> Scalingo has it for a few months [https://blog.scalingo.com/2016/12/24/letsencrypt.html](https://blog.scalingo.com/2016/12/24/letsencrypt.html)

</comment></comment><comment><USER4> Sweet, this is basically want Lets Encrypt wanted, make the market go towards this free SSL model.

<comment><USER5> Companies who aren't in the business of selling TLS [0] certs themselves have little excuse to _not_ offer free TLS via Let's Encrypt. It's an advantage over any competitors who haven't set that process up.

If your company does hosting - your company should provide TLS certs via Let's Encrypt _automatically_.

[0] Can we start dropping the SSL part now? Generally SSL v2/v3 is disabled so it is all over TLS anyway.

<comment><USER6> > If your company does hosting - your company should provide TLS certs via > Let's Encrypt automatically.

Correction: As part of the paid plan.

Why give for free sometimes you can charge money for.

<comment><USER7> If you have a free plan at all, then the only reason TLS should not be a paid feature would be if you intentionally want to position the free plan as "don't take this seriously because you can't build anything production-quality on it".

<comment><USER6> That makes sense for a hosting service. A lot of them works that way. Hosting a static free blog doesn't need TLS.

<comment><USER8> Considering the amount of crap ISPs have been known to inject into websites, I disagree. TLS isn't just for encryption, it also provides data integrity.

<comment><USER9> This is the correct answer. Use this reasoning.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Etsy's blog post is a great primer (as usual) on how to accomplish this kind of thing: [https://codeascraft.com/2017/01/31/how-etsy-manages-https- an...](https://codeascraft.com/2017/01/31/how-etsy-manages-https-and-ssl- certificates-for-custom-domains-on-pattern/)

</comment><comment><USER11> For anyone on the fence about using Heroku, this is a great value to those who know how to deal with certs but wouldn't mind them automated and free for the rest of the premium at Heroku.

</comment><comment><USER12> This is fantastic and will make setting up custom domains with SSL so much easier!

</comment><comment><USER13> Awesome. With the Hobby Dyno pricing and no effort support for Let's Encrypt, Heroku is really hitting a sweet spot for supporting low volume web apps (e.g., less that a 1000 daily visitors).

</comment><comment><USER14> Great news! I was honestly wondering what was taking them so long on this one. Seemed like a no brainer.

</comment><comment><USER15> I believe the title is missing "for all paid dynos"

Which somehow changes its meaning .

</comment><comment><USER16> Does it support wildcard?

<comment><USER17> Does it need wildcard?

<comment><USER17> It's a serious question, if you have unlimited and automated SSL certificates, what is the purpose of wildcards?

<comment><USER18> Dynamic subdomains

<comment><USER17> Does Heroku support that?

<comment><USER19> Of course.

</comment></comment></comment></comment></comment></comment><comment><USER20> Private Spaces not supported :(

</comment><comment><USER21> Great news! So are we any closer to HTTP/2 on heroku?

<comment><USER22> Also Heroku don't support ECDSA (stronger / faster than RSA) yet.

</comment></comment><comment><USER23> _" free for all paid Dynos on Heroku's Common Runtime."_

Not free. Included with purchase.

<comment><USER24> Well, the context is that you used to have to pay for it, and now you don't.

That's the announcement.

</comment></comment><comment><USER25> Free SSL.. for all paid dynos. Apparently, if you're developing an application, you are expected to be okay with having your stuff MITMed.

Yes, this is me being excessively negative. Not having SSL-by-default in 2017 is excessively stupid. The certs are free, the system fully automated from both sides. Why hold back?

 _There is no excuse for not having it system wide._ Unencrypted HTTP needs to start being treated as the danger it is.

<comment><USER26> Free dynos with a ____.herokuapp.com domain have SSL enabled by default, at no cost (under their wildcard certificate?). Seems the only missing case is when using a custom domain with a free dyno.

<comment><USER25> It's an _obvious_ missing case, and one that they are clearly conscious of given the constant insertion of the word "paid" in front of "dyno" throughout this announcement post.

The mentality of holding out SSL as a paid addon needs to end. It needed to end years ago. It had no excuse to not end the moment LetsEncrypt went live.

<comment><USER27> Implementing support for LetsEncrypt SSL does have a cost associated with it, particularly at scale. I think restricting the feature to paid users is totally reasonable, particularly since it's still vastly cheaper than getting a traditional SSL certificate.

<comment><USER25> And what exactly would that cost be? Can it even be quantified?

We're speaking of a 4x yearly ACME request of a few kilobytes going to and from the LE servers. It certainly isn't bandwidth.

The engineering work was already done, and doesn't change based on the number of instances that are making the cert request. It certainly isn't labor.

It certainly isn't storage. Certs are 2-4 kilobytes. Even if we assume Heroku has 5M active dynos and each one has its own unique cert, that's only 20 gigabytes worth of certs, which is miniscule.

So where's the cost coming from? Answer: It isn't. This is just tier differentiation, not cost recovery.

<comment><USER27> Oh my - so, it's actually a lot more complicated than that. Let me run it through for you:

\- You have to build enough of a retry algorithm so that you start renewing well in advance of the expiration date.

\- You then have to build the mechanism for warning customers that there was an issue renewing for one of a variety of reasons

\- You then have to deal with situations where LE has issues, which happens fairly often

\- There's a queueing system, where you have to handle not sending too many certs at once

\- You will end up in scenarios where users will migrate off of you, not tell you, attempt to issue another LE cert with another service, and fail, and then blame you

\- Similarly, you will have users who connect and disconnect domains, and your system has to be smart enough to properly revoke certificates without locking out a domain from too many retries

\- and then what happens when you can't renew a cert for whatever reason? Do you break the user's site? Do you fall back to http?

I'm not saying it's millions of dollars, but at scale, it's complicated. Here's a blog post about how Squarespace did this (disclosure, I work there):

[https://engineering.squarespace.com/blog/2016/implementing-s...](https://engineering.squarespace.com/blog/2016/implementing- ssl-tls-for-all-squarespace-sites)

Saying it's "just" a 4x acme request annually demonstrates a real lack of understanding of supporting this kind of system at scale.

<comment><USER25> I didn't say that it was easy. I enumerated three things that it can't be.

Given that Heroku is already generating certs on the fly for the (randomly named) dynos, offering _that_ is _even more_ engineering work than just sending a cert request for a custom domain, the numbers of which will be significantly smaller. _[DISREGARD THIS - no they 're not. Those are all on a single wildcard]_

My whole gist here is that every conceivable practical excuse I can think of for not extending that feature out to custom domains resolves as a nonissue, which only leaves feature differentiation to drive sales as the remaining option.

Which, as mentioned before, is a legitimate business tactic, but morally _evil_ in the security climate of 201x+.

<comment><USER28> They aren't generating certs on the fly for randomly named dynos:

      -bash-4.1$ curl -vkLs https://wind-river-5693.herokuapp.com 2>&1 | grep certificate
      * Server certificate: *.herokuapp.com
      * Server certificate: DigiCert SHA2 High Assurance Server CA
      * Server certificate: DigiCert High Assurance EV Root CA
      -bash-4.1$

<comment><USER25> Foo! Okay, I thought they were doing LE certs for every dyno's name. One wildcard makes a lot more sense.

<comment><USER28> FTA:

      ACM handles all aspects of SSL/TLS certificates for _custom domains_;
      you no longer have to purchase certificates, or worry about their
      expiration or renewal.

Emphasis mine.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


This $400 appliance that squeezes juice out of a bag appears unnecessary - <AUTHOR> https://arstechnica.com/business/2017/04/this-400-appliance-that-squeezes-juice-out-of-a-bag-appears-unnecessary <comment> et-al Different article, but same story: [https://news.ycombinator.com/item?id=14148216](https://news.ycombinator.com/item?id=14148216)

</comment><comment><USER2> The real bottom line is near the end of the article:

"health experts agree that eating whole fruits and vegetables is better for you than drinking juice"

</comment><comment><USER3> I have a vitamix and I make smoothies with it. Plus, I can make ice cream with bananas + carob powder or cacao powder. This seems really pointless.

</comment><comment><USER4> About 30+ years ago my local supermarket had a machine that would take a box of oranges and make juice out of it and it would pour it right into a bottle. All for less than $400.00. You would set it and walk away. It was fun to watch it go. Much better than what this machine seems to do.

New tech does not guarantee new and better ideas. This is a prime example.

</comment><comment><USER5> > _"775 aircraft-grade aluminum."_

That would almost certainly be the 7075 alloy [1].

> _Byline: MEGAN GEUSS_

Dare I guess at the pronunciation?

[1] [https://en.wikipedia.org/wiki/7075_aluminium_alloy](https://en.wikipedia.org/wiki/7075_aluminium_alloy)

</comment><comment><USER6> "A fool and his money are soon parted"

</comment><comment><USER7> That's a juicy story

</comment><comment><USER8> perfect example of over-engineering a solution to a simple problem</comment>


Continuous Deployments at BuzzFeed - <AUTHOR> https://tech.buzzfeed.com/continuous-deployments-at-buzzfeed-d171f76c1ac4 <comment><AUTHOR> I am part of the team that worked on this project. AMA

<comment><USER2> Do you have any metrics about how efficient the process has become at Buzzfeed? Like Microsoft's 1ES system? - [https://twitter.com/IkeTheDev/status/1230854784686723072](https://twitter.com/IkeTheDev/status/1230854784686723072)

<comment><AUTHOR> Sure. Our numbers are smaller, as our org is much smaller but I think they hold up.

We have under 100 engineers at BuzzFeed, so for us we reduce time spent supporting applications by a single percentage is almost equivalent to having an extra engineer!

On a typical day we'll do 180+ deploys. That'll be roughly 60% stage, 40% production. To deploy outside of continuous deployments (e.g. to push a branch build to a stage environment), is as simple as browsing to our deploy UI, selecting the service you want to deploy, the version, and the cluster to deploy too. It takes an engineer about 40 seconds to do that (time measured from typing URL, to hitting the deploy button)

Continuous deployments means for production deploys for master, that step is automated. So that's a saving (in engineer time) of around 40 seconds per deploy. Over the last month over 1400 deploys were made via continuous deployment.

This means from a developer productivity perspective roughly 2 engineer days per month (1400 deploys * 40 secs per deploy / 3600 to get into hours / 8 hours per day) ) are being saved as a result of this change.

However this is really a side benefit. Our real motivation for making this change was to ensure that all master builds are deployed, and that each of our ~500 micro services is always on latest master.

This is to reduce developer anxiety of deploying over a branch build and thus minimize stress around making change.

The productivity side benefit is pretty nice though!</comment></comment></comment>


WWDC 2020: Rosetta 2 on Apple Silicon Macs and Virtualization - <AUTHOR> https://www.macobserver.com/news/wwdc2020-rosetta-2-apple-silicon-macs-virtualization/ <comment><USER2> I still can't figure out what the deal will be with Virtualization on Apple Silicon. If they just mean that you can run the Arm version of a Linux distro it's not that useful (At least for devs like me who need to write native software for Windows and Linux). But if it actually means you can continue to run x86-64 versions of Windows and Linux at near native speeds, that sounds great. Although I would wonder how that's possible.</comment>


Cuts in movies, and their impact on memory - <AUTHOR> http://scienceblogs.com/cognitivedaily/2009/07/cuts_in_movies_and_their_impac_1.php <comment><USER2> I wonder if this has something to do with the way our brain handles ocular saccades. ( The rapid eye movement we go through when scanning a room, changing the direction of our gaze. More info here: <http://en.wikipedia.org/wiki/Saccade>)

The brain 'cuts out' our conscious vision during these rapid eye movements. just look around the room at several different objects quickly by moving only your eyes. You will discover an almost complete lack of visual information between points A and B. You would expect to see a blur of movement for a fraction of a second while your eye moves to the new target, but your brain edits this out.

It seems at if a cut during a film could be roughly equivalent - I wonder if some of the information directly preceding or following the hard cut gets edited out by your head becasue it perceives it as a visual anomaly or artifact, much the same as during a saccade?

To another point in the article- edits in film aren't (or shouldn't be) used primarily to keep the viewers interest. During a narrative, a cut should is made to bring context or to move the story forward. This was the way editing was first introduced in fact. Cutting for cutting's sake isn't generally considered good editing.

<comment><USER3> "You would expect to see a blur of movement for a fraction of a second while your eye moves to the new target, but your brain edits this out."

With a bit of effort, I was able to override this. Try it and you'll see why that gets edited out; there isn't much usable information there.

<comment><USER2> You can force yourself to see during rapid eye movement by tracking a fast- moving object such as your finger and paying attention to the background in your periphery.</comment></comment></comment>


How Not to Be Alone (2013) - <AUTHOR> https://www.nytimes.com/2013/06/09/opinion/sunday/how-not-to-be-alone.html?pagewanted=all <comment><USER2> >I'm not sure how else to describe somebody completely fixated on a small device, resorting to it almost like some security blanket when an everyday problem needs solving. Portable video games like Game Boy, and traditional mobile phones, which no doubt have been similarly derided in the past, offer a poor comparison for their limited scope. The small screen provides some strange tunnel vision I don't care to encounter.

This comment from the previous discussion struck me. I remember this and how weird it seemed, how at times people were derided for using their phone in public. It almost seems quaint now. These days I find you get strange looks from people if you don't have a phone on you. Asking someone for the time is almost met with suspicion I find. As though they assume something's wrong with you for not having a phone to check the time.

</comment><comment><USER3> Discussed at the time: [https://news.ycombinator.com/item?id=5846603](https://news.ycombinator.com/item?id=5846603).

(Also, we changed the above URL from [http://www.calnewport.com/blog/2019/09/26/how-not-to-be- alon...](http://www.calnewport.com/blog/2019/09/26/how-not-to-be-alone- jonathan-safran-foer-on-the-dangers-of-diminished-communication/), which points to this.)</comment>


Insurers Want to Know How Many Steps You Took Today - <AUTHOR> https://www.nytimes.com/2019/04/10/opinion/insurance-ai.html <comment><USER3> Each insurable loss like a car accident, house fire or heart disease, has two contributors: inherent risk, and behavior. (Inherent risk is risk you can do nothing about - age, gender, genes).

To the degree that AI can help reduce or measure behavioral risk, it's not only a good idea but only fair. I think most people would admit pricing insurance based on people's behavior is fair. They certainly do not like the idea of paying for others' right to drive fast and stop short. AI is a tool that is accelerating this trend.

All of the scary things mentioned in the article actually have nothing to do with AI, but discrimination based on inherent risks. Pricing insurance on ZIP certainly does not require AI. And while genes are a medical factor, getting old is the #1 inherent medical risk.

Is it fair to price on these things? For a house, ZIP makes sense - <USER2> risk differs. But it is likewise undeniable that the old will cost more to care for than the relatively young. Debating AI won't help - the real debate is about whether we as a society are willing to protect people from the inherent risks of getting old, childbirth, cancer, living in a floodplain or wildfire zone, or even growing up in a poor area. We don't really have an honest debate about that.</comment>


The NICAM Codec replacement project - <AUTHOR> http://www.bbc.co.uk/rd/blog/2016-01-35-million-people-didnt-notice-a-thing-dot-dot-dot <comment><USER2> That's some decent BBC engineering from a team that works away quietly in the background and just makes things happen, or keep happening. I don't work in that field, but like many people in my profession (Systems and networking), I also tend to be invisible until something breaks, and then I am the fall guy if it's not fixed within a heartbeat.

/I was half expecting the article to outline how a box full of 80s technology had been replaced with a Raspberry Pi!

<comment><USER3> "I was half expecting the article to outline how a box full of 80s technology had been replaced with a Raspberry Pi!"

The Parallella computer, which looks a lot like a Raspberry Pi, has a Xilinx Zynq chip similar to the one in the BBC's new codec. So it's almost true.

<comment><USER4> Here's the exact board that's in there:

[http://store.digilentinc.com/zedboard-zynq-7000-arm-fpga- soc...](http://store.digilentinc.com/zedboard-zynq-7000-arm-fpga-soc- development-board/)

<comment><USER5> It is a bit odd that they shoehorned in an existing commercial board rather than just put the FPGA on the main board or even designed a custom daughter card if upgradability was a concern. As it is, they are now tied to the availability of boards with the same board-to-board connector and a similar form factor.

<comment><USER6> They used a commercial board that implements the Vita 57 bus, which is the standard way to interface with an FPGA [1]. So if they need replacements down the road, they just have to get one that implements the same standard, and standards for industrial equipment tend to stick around for a considerable amount of time.

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

</comment></comment></comment></comment></comment><comment><USER7> This is one of the most interesting things I've read on HN in weeks. Awesome to see this kind of success story, and it's super fascinating to get insight into how radio works behind the scenes.

I'll be honest, I had no idea all of this goes into radio. I thought there were just, err, towers?, that broadcast... radio waves, and that was kind of it? I mean, I knew on some level it had to be a tad bit more complex than that, but you never see or hear about it.

<comment><USER8> Well, I'd assume that the reason for radio silence (ahem) on broadcasting tech would be various NDAs.

<comment><USER9> It has been claimed that a literal radio silence of BBC could cause a nuclear strike.

[https://en.wikipedia.org/wiki/BBC_Radio_4](https://en.wikipedia.org/wiki/BBC_Radio_4) (C-f nuclear)

<comment><USER10> Here's the article it links to, pretty interesting in and of itself:

[http://www.manchestereveningnews.co.uk/news/greater- manchest...](http://www.manchestereveningnews.co.uk/news/greater-manchester- news/radio-silence-puts-subs-on-nuclear-1157478)

"Secret orders to the captains [of the nuclear subs] say that these deadly instructions are to be opened and acted upon only if the submarine cannot tune in to Radio 4's Today programme for a given number of consecutive days. That is a reliable sign that Britain has been hit by a nuclear attack."

<comment><USER11> Que new James Bond plot, the bad guy disables radio 4 to launch nuclear armageddon - Bond in race against time to find the spare parts needed to restore the radio.

</comment></comment></comment></comment></comment><comment><USER12> I've always been impressed by the BBC tech people I met, doing a high-quality job in an extremely bureaucratic neophobic environment.

 _As part of making the unit, we had to ensure it complied with all the relevant European directives so that it could be CE marked. We had the Codec tested for both safety and EMC._

Interesting, I thought this wasn't required for internal use; probably the BBC corporate structure means it no longer counts as "internal".

On "Radio Teleswitch":

 _[Droitwich] transmitter uses a pair of obsolete metre-long valves which are no longer manufactured anywhere in the world.[1]

In October 2011, the BBC admitted that the Droitwich transmitter, including Radio 4's longwave service and Radio Teleswitch, will cease to operate when one of the last two valves breaks, and no effort would be made to manufacture more nor to install a replacement longwave transmitter._

This is like the Domesday Book (1980s interactive multimedia system on Laserdisc): high-tech and sui generis at the time it was built, but eventually uniquely obsolete.

The BBC itself is very much a valve-and-laserdisc organisation in a Google world. We huddle round the warm glow, concerned that eventually some vital element will give out due to lack of money and the whole enterprise will give up.

Periodically someone comes up with the idea of shutting down analog FM radio. This is politically inconceivable as half the country has ancient radios that were tuned to Radio 4 in 1967 and have never played any other station (an exaggeration, but only a small one).

<comment><USER13> CE carries a number of subclasses that can be self-certified.

With respect to EMC and safety it is absolutely in their best interest to conform, not merely out of a bureaucratic obligation but out of a need to minimize any interference from or to other equipment housed nearby.

Radio Teleswitch stuff is cool.

</comment></comment><comment><USER14> > In addition, the signalling information for switching Economy 7 electricity > meters is carried on Radio 4 LW.

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

Fascinating stuff.

<comment><USER15> Indeed

         to allow electricity suppliers to switch large numbers of electricity meters between different tariffs by broadcasting an embedded signal in broadcast radio signals

I kind of heavily doubt these are signed broadcasts that cannot be replayed..

<comment><USER8> Something akin to this? [http://gpsworld.com/wirelessinfrastructuregoing- against-time...](http://gpsworld.com/wirelessinfrastructuregoing-against- time-13278/)

I believe that operating a rogue transmitter in a licensed band would get you located rather quickly - even though the tech itself may not necessarily be secure, there are other enforcement mechanisms.

<comment><USER16> It depends how strong it is.

The obvious benefit for a malicious person would be to set their meter to the cheaper tariff by replaying the signal.

It wouldn't need to be a powerful signal - if you were broadcasting right next to the meter even a few milliwatts would be enough. Build a faraday cage around the meter to be sure! Just remember to dismantle it before the meter reader comes round.

<comment><USER8> That would also disable the legit switching, no?

</comment></comment></comment></comment></comment><comment><USER17> I can see from the photos that it's using this board: [http://zedboard.org/product/zedboard](http://zedboard.org/product/zedboard)

I'm surprised BBC is not only willing to make custom hardware, but custom RTL design as well.

I'm curious what the failure rate of the FPGA will be, I mean they are more susceptible to soft errors than CPUs or ASICs. Maybe BBC will fund making a custom ASIC :-) Well I see two systems, maybe they are redundant that way.

Why not make the project open source? Put it up on github.

<comment><USER18> I would doubt an ASIC would be worth it, giving the number of organisations needing this CODEC would be relatively low. An ASIC run is expensive and even more expensive if there is subsequent error in the design.

FPGA makes sense for this application. It can always be re-flashed.

<comment><USER17> They should at least enable the SEU mitigation circuit, which repeatedly performs CRC of the configuration data. Have it reboot if it detects an error. Maybe they already do this.

I checked, Zynq-7000 has this capability: [http://www.xilinx.com/products/intellectual- property/sem.htm...](http://www.xilinx.com/products/intellectual- property/sem.html)

</comment></comment></comment><comment><USER19> Very nice work. What is the rationale behind doing a bespoke design rather than sharing the development cost with all the European broadcasters, is NICAM unique to the UK? What do other broadcasters use for similar services?

<comment><USER20> [https://en.wikipedia.org/wiki/NICAM](https://en.wikipedia.org/wiki/NICAM) seems to indicate that while NICAM is used by a few broadcasters here and there, it was initially developed by the BBC, and it's no longer as widespread in Europe as it once was.

<comment><USER21> See makomk's comment nearby: NICAM's use for stereo sound with analogue TV broadcasts is not the same as the use for the BBC's internal audio distribution system.

</comment></comment></comment><comment><USER22> Somewhat related, a few years ago I saw a video of a guy starting up a "live TV studio" from 70s/80s I think at his cottage/cabin. It was quite interesting, unfortunately not in English. I'll try to find it anyway and update this post.

edit: Here's the video I had in mind [https://www.youtube.com/watch?v=51F7zNWqlgM](https://www.youtube.com/watch?v=51F7zNWqlgM) I guess it's boring without understanding the audio :)

There's more on his channel

</comment><comment><USER23> I appreciate a good success story about major transitions / upgrades / process changes / etc. Those situations where there is usually SOME glitch and you have to engineer the hell out of it to get a perfect transition. The only reference to testing was "We had the Codec tested for both safety and EMC." Was that in house or external? Surely there was some major transition testing low power broadcast tests, etc to make sure everything went smoothly. Or did they just get really lucky? Seems like there's more story to this.

</comment><comment><USER24> Truly an impressive feat:

"When you do things right, people won't be sure you've done anything at all." \- Futurama

</comment><comment><USER25> Thats awesome! People easily overlook these things. They hardly realise that its same as upgrading an aircraft in midair.

</comment><comment><USER26> I read the article with interest, waiting with anticipation for them to announce the resulting hardware and software had all been open sourced. And then...nothing.

I'm surprised, I thought in the UK these kinds of taxpayer-funded projects were required to be open source.

In any case, it's too bad. I was not familiar with the NICAM codec up to now, but I'm sure that software and hardware plans would have been very useful to some developing countries, many of whom apparently also use NICAM in their state-owned broadcast companies.

<comment><USER27> _> I thought in the UK these kinds of taxpayer-funded projects were required to be open source._

There is no law, afaik, and even the BBC has commercial interests. iPlayer has never been open-source, for example.

The BBC has obligations in terms of content reach and content quality, but they're not particularly bound to specific ways of achieving those targets (beyond some stuff about not abusing their position in commercial terms). Actual engineers are mostly pro-OSS and try hard to push for it internally, but they have legal obstacles similar to any other company.

</comment></comment><comment><USER28> Will be interested to read the followup article in the year 2048 regarding whether these new boxes lasted as long as their predecessors.

<comment><USER29> Great idea. I tried to set a reminder, but my calendar only goes to 2038.

<comment><USER30>
      unsigned int epoch;

</comment></comment></comment><comment><USER31> Honest question -- why are they using PATA ribbon cables in the new NICAM codec box? Surely SATA would be more reliable and easier to administer.

<comment><USER32> They most likely aren't ATA cables, as in, they aren't used to connect hard drives -- so it's not obvious that whatever purpose they serve could be served by a serial alternative.

If you look at the photo of the back of the unit, you see a lot of very wide D-Sub sockets that these ribbon cables seem to connect to, so the unit is meant to connect to a bunch of other things. Actually, the need for these sockets seem to account for most of the size of the unit, the box appears pretty empty.

<comment><USER33> If you're designing your own boards with ribbon cables connecting them, I imagine that you could save a lot of money on parts by using 40-pin connectors with PATA cables--we're talking entire cents, for each of the 2 units.

Also, I'm willing to bet a place like the BBC has boxes filled with spare PATA cables and 16MB SIMMs and 8 GB internal hard drives, and maybe even a room with a bunch of dusty 17" CRT monitors in it. And sometimes, rather than fill out a purchase order, one of the engineers descends into the hoard, returns with a cobbled-together frankenserver, and installs NetBSD on it.

So they might actually be PATA _cables_ using PATA _connectors_ , but the signal between cards is not ATA.

<comment><USER12> Exactly. And it has to connect to the same system as the original 1980s units, so whatever protocol it's using will be old. DB25-serial? SCSI? IEE-488? It would have been nice to have a few technical details on the system.

Random BBC-related anecdote: the Cambridge University computer lab had, up to 1999, an info TV in the lobby driven by a 20 year old BBC micro in Teletext mode. This was apparently because it had an extremely powerful video output (more so than modern hardware) and the display was at the other end of 50m coaxial cable.

<comment><USER34> The display was slaved via coax to, I think, four or five CRTs around the site. I don't know if there was a separate amplifier/splitter or not.

It lasted a few years past 1999 - it was still in service for some time after I returned in 2002.

</comment></comment></comment></comment></comment><comment><USER21> What I missed in the article is whether there was an audible glitch at 4:15 AM.

</comment><comment><USER35> Really interesting article, but terrible clickbaity title. I wouldn't have read it if there weren't so many positive comments on HN already.

It could work if there were a subtitle. "35 million people didn't notice a thing: BBC Radio's NICAM Codec replacement project". I dunno. But it is (or should be) very important that the title actually informs you as to what the article is about. "35M people didn't notice a thing" doesn't tell you anything at all.

Edit: Upon further consideration I may have been a little harsh. This is really a blog entry more than an "article" per se, and I suppose that's fine for a blog post title. The problem comes when we link to it from somewhere else, e.g. HN; we need the additional context.

<comment><USER36> Perhaps the title-writer has been infected by the BBC news editorial policy. They seem to be turning clickbait titles into a fine art, combined with renaming articles so you think it's a new piece on the same story, but turns out you've already read it. (If you read BBC News at all that is: my wife still does, I gave it up years ago and haven't looked back.)

I love many aspects of the BBC but sadly not their news output anymore.

(Sorry I realise this has very little to do with the R&D article.)

<comment><USER37> I used to think the BBC news was definitive 5-10 years ago. I'm not sure what has changed? Have the recent governments and their pressure on the license fee really made the difference or is it just my perception?

When I was young the BBC was always seen as pretty left wing (it certainly wasn't at it's inception though) it seems pretty conservative (and sensationalist) right now.

<comment><USER38> Both sides of the political spectrum regularly complains about the BBC being biased towards the other side. It's the best evidence that whatever bias there is either is minor or short-lived.

In my eyes, the biggest problem with the BBC isn't bias, but that they're terrified of seeming too biased, and as a result they're wishy-washy in ways that ironically makes them seem biased.

E.g. the left will accuse them of being right wing because they don't write in more critical terms about the governments willingness to deal with the Saudis, while the right will accuse them of a left wing bias for not writing in more critical terms about Chavez, and so on. Similarly they're often accused of bias for not reporting something, or very carefully reporting something, that either side believe to be fact, but where there's not (yet) actual firm evidence. Of course, if done "against" just one side, this too would be actual bias, but the BBC appears to be pretty consistent about it.

So we're left with reporting that is rarely very biased, but often exceedingly unsatisfying for everyone.

I'm not saying there's no bias - I don't believe that would be possible. But I do think that the allegations of bias against the BBC tend to be wildly exaggerated.

<comment><USER39> There was a comment here a few months ago which mentioned a term. I have forgotten the term since but it effectively described a situation where an expert in subject matter foo reads an article about foo in a well-regarded news source (like say the Economist) which is either pretty incorrect or pretty biased and then the subject matter expert goes "wow they know nothing about foo" and then turns the page and reads about another topic let's say bar (or maybe let's say Middle East politics) which our subject matter expert knows little or nothing about and then our subject matter expert says "wow, this news source is very insightful".

If we read about articles on key escrow or actually anything about cryptography and surveillance in general, we will find it hard to see BBC is accurate (neutral is not the same as accurate because to be neutral about anything -- and here comes Godwin's law -- involves saying that there was a legitimate excuse governments to act in a way that is not beneficial to millions of its citizens. Anti-terrorism rhetoric is way overboard and news outlets like BBC are fully on the bandwagon (although thankfully much less so compared to CNN, Fox News, and other low lives). Honestly, I think our fear of terrorists has caused more damage to the world economy than all the "acts of terror" combined. Ordinary people should not be afraid or even mindful of "acts of terror" in their daily life any more than they need to be afraid or mindful of a meteor shower hitting them in the head. Everyone goes over the top with "security precautions" because they don't want to be seen as doing nothing. The point here is BBC does not preserve this neutrality at all. I bet even CNN and Fox could do better if they were organizations that has their funding guaranteed, as opposed to being under the mercy of its advertisers. Sorry but what BBC does is nothing exemplary for someone in its shoes.

<comment><USER40> It's called the Gell-Mann Amnesia effect, a name coined by Michael Crichton: [http://paul.kedrosky.com/archives/2011/07/the-gell-mann- amne...](http://paul.kedrosky.com/archives/2011/07/the-gell-mann-amnesia- effect.html)

</comment></comment></comment></comment></comment></comment><comment><USER41> good !!!!!!!!

</comment><comment><USER42> Top on HN, but I can see why. The title tempts you to click through. :)</comment>


EBay glitch blocks access for users on auction site - <AUTHOR> http://www.bbc.com/news/technology-29054972

<comment><AUTHOR> Any bets on how much money is being lost? Posts all over the interwebs of people missing auctions.

Official response is that the issue is limited to "a portion" of users.

[http://www2.ebay.com/aw/announce.shtml](http://www2.ebay.com/aw/announce.shtml)</comment>


Sandberg: Men still run the world – and it's not going that well - <AUTHOR> http://www.weforum.org/agenda/2016/01/sheryl-sandberg-men-still-run-the-world-and-it-s-not-going-that-well <comment><USER2> This article contains more logical fallacies than the movie Spaceballs</comment>


Japanese F-35 in the Pacific, cue biggest counter-espionage ops since Cold War - <AUTHOR> https://www.businessinsider.com/japan-lost-an-f-35-in-the-pacific-russia-or-china-may-find-it-first-2019-4 <comment><USER2> Found.

[https://www.reuters.com/article/us-japan- defence-f35/wreckag...](https://www.reuters.com/article/us-japan- defence-f35/wreckage-confirmed-to-be-from-crashed-japanese-f-35-fighter- idUSKCN1RM011?il=0)

</comment><comment><USER3> The first thought that popped up in my mind while reading this was, "Why doesn't this plane have self destruct mode?"

<comment><USER4> In this case, I believe that "self-destruct mode" is called "crashing into the Pacific Ocean."

This article feels disingenuous. They make it out like they Chinese or Russians are going to just stumble upon a nice, neat F-35, ready for inspection.

<comment><USER5> There was an incident some years ago where an EP-3R recon plane was forced to land by PLA fighters. Flight crew had a few mins to destroy critical components but the Chinese gathered some tech from that incident. Also, the unlucky Gary Powers.

<comment><USER6> > was forced to land by PLA fighters

I won't necessarily say the landing was forced by PLA fighters; that would imply PLA intentionally did this (to obtain tech?) while in fact that J-8 crashed and its pilot was killed/missing. US recon planes fly near China's (and other countries') coastal line with PLA's fighter near by all the time.

My point is that incident looks more like an accident to me even though China may have gained some tech out of it while losing one pilot and plane.

</comment></comment></comment></comment><comment><USER7> Can Russia even afford to build an aircraft as expensive as the F-35?

<comment><USER8> Probably not at any scale beyond serial production, even then, there isn't a Russian powerplant that would offer the thrust/weight performance required for the plane to perform.

I'm sure some of the materials on the F-35 would be very difficult for other countries to make at scale, figuring out how to fabricate parts out of those unusual materials at tolerances required for low-observability would be really tricky. I'm sure there are machinists anywhere who could figure it out, but at that point we're talking about bespoke part production using 98th+ percentile operators. Although skilled labor is cheap is China and Russia, it's pretty untenable to use it to produce a knock-off that'll eventually hold an inferior Chinese/Russian engine.

<comment><USER9> While Russian doesn't have a powerful engine as the F-35, their newer planes have twin engine with a combined output larger than the single engine of the F-35.

<comment><USER8> Yeah, but thrust to weight really matters too. I'd be floored if two Russian engines had anywhere near the power to weight ratio of the F-35 engine.

But the Russian engineers are very good, they've done a great job of designing competitive planes with those constraints. I wouldn't cast stones at the prototype Sukhois or MiGs.

</comment></comment></comment></comment><comment> daniel-cussen "But the jet's all-important software and programming would likely be hard to reconstruct given not only the likely damage from the crash and salt water in Pacific but also the way that the jet's sensitive systems are designed to be very hard to decipher and reverse engineer to make it more suitable for export."

Funny I thought the software was repeatedly reported as being its greatest liability.</comment>


Manjaro Linux Announcement About Its Future - <AUTHOR> https://www.forbes.com/sites/jasonevangelho/2019/09/08/manjaro-linux-just-made-a-massive-announcement-about-its-future <comment><USER2> Blogspam for real source: [https://forum.manjaro.org/t/manjaro-is-taking-the- next-step/...](https://forum.manjaro.org/t/manjaro-is-taking-the-next- step/102105)</comment>


Show HN: A free low tech productivity tool to help you beat procrastination - <AUTHOR> http://focusplanner.co/ <comment><USER2> Hi...I am able to perform multiple download requests with the same email id.</comment>


Ask HN: How do you avoid staying too late at work? - <AUTHOR> How do you avoid the urge to stay later at work than you should be staying? <comment><USER3> If you are talking about being overburdened by too much work, here's my thoughts:

I prioritize. I get as much as I can done in my usual 40 hours, maybe 50. Anything left undone apparently wasn't high enough priority, so gets dropped. I either delegate it or ignore it.

I used to put in long hours and scramble to do lots of extra work. My company pays me for 40 hours a week, so they get the highest value work I can do for those 40 hours.

If you're not using discretion and simply ignoring some things, you're not working effectively, you're being an automaton with no judgement. There's a lot of low-value things people request you to do or be involved in at work. You have to blow some of it off or you're wasting your own potential and time.

\-- Don't anybody read into this I'm some kind of time-guarding jerk at work. This is my general mindset, but being practical and adaptable is important, as is being sure your manager agrees with your assessment of priorities.

</comment><comment><USER4> You get up at the time your contract says and you go to home.

Its a matter of expectations, if you usually stay late, people will expect that you will be there. Its like if your boss gives you 10 things to do and you accomplish all of them, the next time it will give you 12 things to do, then if you stay late working on those things and you deliver the next time your boss will give you 14 things, because he is measuring your throughput of work

The solution is simple, just stand up and leave and talk to your boss about the amount of work so he can hire someone to help you or delegates the work to other person.

<comment><USER5> > You get up at the time your contract says and you go to home.

Are you American?

The vast majority of the American workforce is "at will." There is no contract.

> he solution is simple, just stand up and leave and talk to your boss about > the amount of work so he can hire someone to help you or delegates the work > to other person.

This is exceedingly dangerous. You are telling people to go to their bosses and say "hire someone to do the job you hired me to do."

Source: practicing attorney.

<comment><USER4> I'm not from USA.

I don't understand why is it dangerous, can't you say that in the USA to your employer? It's just asking for help because you're overwhelmed with your job.

<comment><USER5> > I don't understand why is it dangerous,

Because you may get fired. Before this devolves into a philosophical argument, I am not saying this is right, or that there aren't many valuable employees and skill sets who are less at risk of this sort of termination, or that there are many good and valuable ways to negotiate these things with your boss. But the advice of simply stating you get up from your desk to leave at the end of your contract time _is_ dangerous. This is highly context dependent.

Communication is good. Put in the effort, go the extra mile _and_ tell your boss your are overwhelmed. Don't just get up and go home at the stroke of [5:00] or [6:00] or whenever it is.

Disclaimer: this is in no way a legal opinion and I am not your lawyer. If you need a lawyer, get a lawyer, especially if you have an employment related dispute. Further, I am not advocating a harsh managerial style - I am not advocating anything, except to not unnecessarily risk your jobs.

</comment></comment></comment></comment><comment><USER6> Get married and start a family. Seriously when you become a husband/father (or wife/mother) your priorities will (should) shift to your new dependents. It's not only about the money anymore, quality time becomes just as important.

In lieu of that, just start an activity that demands your time and is as (if not more) important to you as work such as coaching a kids team, helping out at the YMCA or YWCA, etc...

</comment><comment><USER7> When you hit the point of saying "if I just work _one more hour_ I'll solve this", remind yourself that working long hours is counter-productive. And remind yourself of all the times you came in to work in the morning and figured out the impossible problem from the day before in just 5 minutes.

(Long version: [https://codewithoutrules.com/2016/02/24/go-home- already/](https://codewithoutrules.com/2016/02/24/go-home-already/))

</comment><comment><USER8> It's all about managing expectations. If your boss gives you a task and budgets 5 days to it, then do it within the 5 days. If you know up front that there is not enough time budgeted for it, then raise that. Your manager will like you better for it. If you finish early that's good, get started on your next task or learn something but don't tell anyone. Better yet, if it is a repetitive task figure out how to make that task more efficient. If you are a programmer - write a script, if you are a lawyer/accountant - develop a pre- filled template, etc. Doing this will set expectations from your boss, manager of what you can and can't achieve in the timeframe given, and whether more resources are needed. I can't speak for Americans, but Australia has a contract for specific hours - around 37.5 hours in a week is the government standard. To that end we can be upfront with managers/bosses about expectations and resources and usually it is dealt with.

Source: ScrumMaster and developer

<comment><USER9> > If you finish early that's good, get started on your next task or learn > something but don't tell anyone.

Why? Is this because it will raise expectations?

<comment><USER10> I wish upon everyone a working relationship where honesty has more value, for all involved, than "don't tell anyone" tactics.

</comment></comment></comment><comment><USER11> Realize that sometimes taking a break and going home actually helps you solve problems better.

Understand that you can never ever finish work. Work will always be there and we should not define how successful we are by how much work we do.

<comment><USER12> How many problems have you solved at home in the shower while shampooing your hair?

I do all my best work in there and I can't even bill for it.

<comment><USER13> I have occasionally billed for time spent in the bathtub. I didn't go into the tub expecting to be paid for it, but once in a while I have a eureka moment, get out, write down a solution to a long standing/hard problem, bill a half hour for it, and go back to the tub.

It's rare, and I only bill it when it was genuinely valuable, but it's not totally out of the question!

<comment><USER10> This sounds like some kind of contracting relationship. I have a regular daytime job, but contract in my own time, and I find that that is a much better construction for me to weigh putting in more time, getting paid, versus taking my rest (or whatever you want to do when not working). That might not work as well for others, though. My day job, at fixed pay, excites me a lot, which is a reason to put in too much time. I have no over-demanding managers, forcing me to stay late, like others may have. So, here's at least three powers that may make someone stay late, each with its own countermeasures, all very dependent on that individual or their situation. I'll repeat them: excitement/involvement, money (hourly rates), and scare of being fired.

<comment><USER11> At the end of the day, it comes from one's own motivations and I do feel your sentiments regarding the 3 powers you mentioned.

1\. Excitement/involvement is tough to manage but at the end of the day, if you're burned out, the excitement dies down. At least that's what happened to me. And as mentioned, there are times when I didn't think of how to solve a problem that the solution came to me.

2\. I had to overcome the obstacle of money and the fear of being fired. In the past, it used to affect me greatly but I've learned how to deal with it over the years through chanting (meditation), philosophy and other activities.

</comment></comment></comment></comment></comment><comment><USER14> If you want to leave at a consistent time, one technique is to make a fixed- time commitment after work, eg, schedule the gym from 6-6:30 M-F. Then stick to this consistently and make it clear to those you work with.

</comment><comment><USER15> Never set the expectation that you'll work any more than 8 hours. If you're learning something and feel like you need to put in more then go home learn where you're comfortable. Alternatively find an employer that values you. I made the mistake once of working over consistently. I was stuck at a place that I was working 14-16 hours a day (Come in at 5AM leave at 9PM), just to get the work assigned to me done. I found another employer that valued me and my time.

</comment><comment><USER16> Here is one way:

"OK, enough of the office; I'm going to go home and work from there. Beat traffic, get home before dark."

But then not actually end up working from home.

</comment><comment><USER17> You didn't tell why you feel an "urge" to stay later at work.

My advice is to come into work early.

The tech field is especially lax in time. The majority of my jobs have been 10-6, where my current job is "come in sometime before 10 and 11".

The problem with this is you feel you now need to stay late into the night. You came in at 10:30? Well, I guess it's understandable to be here until 7. This is how paradigms eventually shift to allowing yourself to work until 8pm or later, even if it means you've now worked a 10 hour day.

I agree with a few of the commenters here who talk about routine.

If you show others that you are coming in late, then they expect you to work late.

If you show others that you are there before they are, then it's more reasonable in their minds that you leave before they do.

If you continually show up early to work, then people will not even question or think about it that you leave early (or on time).

</comment><comment><USER18> Two things happened around the same time so I can't say for certain which had the bigger impact. I was a habitual over worker. I would try to beat rush hour on my drive in, and leave after it was over. Then, shortly after the birth of my son, we gave up the second car and I started taking the train to work. Now instead of waiting for traffic to die down, I have to get out right on time to catch my train. When my boss tried to give me little jobs at the end of the day i could say, "Sorry have to catch the train." Eventually my boss got use to it and stopped trying to give me work just as I should be leaving - <USER2> me emails for the morning instead, and balance is much improved.

</comment><comment><USER19> I don't. When that urge comes up, I indulge it, because it means I'm in a flow state and I'm getting a lot done. But eventually I'll get hungry, or finish mining out that particular vein of opportunity; then the work will stop feeling so compelling, and I'll leave.

The rest of the time, I leave work at a reasonable time because I have lots of other things I want to do with my life, and if I spent all evening at work I wouldn't get to pursue them.

</comment><comment><USER20> I get up and walk out the door.

If they want to fire me for working 8 - 8.5 hours, have fun with that because I don't want to take part in being overworked. My productivity goes way down after a while so there is no point in me grinding.

Humans have a limited capacity for everything and need to recharge. Even if you love the work, you need to take a break, eat, sleep, etc.

</comment><comment><USER21> My commute time inflates by 30-50% (and no seats!) if I don't leave AT 5. My manager knows this. I tried leaving 5:30 a few times, the 2-3 hour trips made my weeks hell. Previous jobs I just walked out the door, at a startup too.

</comment><comment><AUTHOR> Thanks everyone and this is great advice. Most of the thoughts here are about standing up to a manager.

In my case I am the manager. A big part of my urge to stay is I feel I do not want to leave before employees. I arrive early and on schedule. But my staff has flex time and they can get here whenever. So basically I am working a shift and a half.

The sad reality is that people don't work nearly as hard when I am not around. So that is the thing that is motivating me.

Also employees ask me these stupid questions at 5pm. Usually I really want to answer because I feel my role is to help them under any circumstance.

<comment><USER11> I feel you. As a manager/leader, I feel the same way.

Here's how I would deal with the situation: You work as hard as you can and support your team as much as you can. At some point, you'll need to build their trust and respect such that they will be willing to work even when you're not there.

You'll have to learn new ways to motivate your employees to work as hard. It's about them learning how to let them take ownership/responsibility over tasks.

With regards to 5pm questions, that's the reality of managers/leaders. We're there to support and assist as much as we can.

If they can feel that you're there for them, they will work for you. Sometimes it might take you bending your back for their needs. Talk about non-work related stuff. Figure out what motivates them and makes them excited and help them get to where they want to be.

Some people may never feel motivated to work beyond what their tasked to do and that's ok. You do what you can but at the same time, know that you can't change everyone. People have to want to change themselves. You're just there to guide.

</comment></comment><comment><USER22> I have a low paying, tedious, non-technical job, so I have no such urge. I work to pay the bills, I write code on the side because I enjoy it and now and then make some money.

Life is too short to care more about making someone else rich than you should.

</comment><comment><USER23> I have interests outside of work that I enjoy.

</comment><comment><USER24> if i had such an urge id book a therapist at 5pm every day until the urge went away, if only because the habit to leave the office was formed by having to see the therapist

</comment><comment><USER25> I have small children. Often, they need to be picked up from where they are. Not infrequently, I do another hour of work on the laptop after bedtime, but that too is limited my awareness that one or the other of my kids is likely to wake me up in the middle of the night and I'll be useless the next day if I don't go to sleep soon.

</comment><comment><USER26> Girlfriend and/or dog

</comment><comment><USER27> I'm contracted for 39 hours and work at most 40 hours - to be honest I'm usually brain dead every night after work, and mindlessly indulge in tv until I fall asleep at 10pm ready to start the day anew.

</comment><comment><USER28> We scheduled family dinner at 5:15 and then I told all my coworkers about it. They think it's cute and appreciate that I'm not staying later than them anymore.

</comment><comment><USER29> Is there a way? My boss uses me as a driver, so I am here early and sometimes am not off until 7:00. The no overtime is great!

<comment><USER30> Either your boss is paying you legally or not. If not being paid legally, why do you not feel you can advocate for yourself, or find a different job? You may have reasons, I'm just curious. You should not have to drive your boss around for free. Or work more than 40h a week without overtime pay, unless your position is exempt from overtime.

</comment></comment><comment><USER31> I work from home so there is zero chance I will stay too late at another location to work.

</comment><comment><USER32> Come in early and kick ass.

<comment><USER33> Umm, no. That defeats the purpose. The purchase is to work a reasonable amount of hours, like 8.

<comment><USER32> A large percentage of the tech workers I have worked with get into the office rarely by ten and often much later around noon. Then they "stay late" until eight or ten or even midnight but when meals and breaks are accounted for they barely put in eight hours of work. An alternative is to arrive at a more traditional work start time and minimize time spent on meals and breaks. This is not about spending more time working but rather about allocating time carefully and densely in order to have a good chance of not staying late.

</comment></comment></comment><comment><USER34> Have a life outside of work

</comment><comment><USER35> I rarely have such urges

</comment><comment><USER36> WFH</comment>


Asking users questions never increases security - <AUTHOR> http://utcc.utoronto.ca/~cks/space/blog/tech/SecurityQuestioningUsers

<comment><USER2> Wow, that makes sense. But isn't "asking users questions" the rationale for UAC in Vista and Windows 7?</comment>


China's crowded labour market is making life tough for foreign workers - <AUTHOR> https://www.scmp.com/economy/china-economy/article/2185133/chinas-crowded-labour-market-making-life-tough-foreign-workers <comment><USER2> Above all is about Chines market _growing_. Total number are _up_. That's logical. When it was in its early years, the few companies with the determination to run the shop there had labour costs as the last concern (completely contrary to the popular belief.) Now, when it is up for normal people to run businesses, most of them have far more common sense and caution with hiring expensive cadres.

</comment><comment><USER3> As opposed to...? Most countries make life hard for immigrant (especially unskilled) workers?

<comment><USER4> you obviously did not read the article. It clearly explains the answer to your question.</comment></comment>


What managers really do - <AUTHOR> http://www.uu.edu/personal/bnance/318/mintz.html <comment><AUTHOR> An excerpt, describing the fragmentation of managers' time:

Folklore: The Manager is a reflective, systematic planner. The evidence on this issue is overwhelming, but not a shred of it supports this statement.

Fact: Study after study has shows that managers work at an unrelenting pace, that their activities are characterized by brevity, variety, and discontinuity, and that they are strongly oriented to actions and dislike reflective activities.

Consider this evidence:

\- Half the activities engaged in by the five chief executives of my study lasted less than nine minutes, and only 10% exceeded one hour.

\- A study of 56 U.S. foremen found that they averaged 583 activities per eight-hour shift, an average of 1 every 48 seconds.

</comment><comment><USER2> Essentially, managers put out fires.

Whenever I start feeling underemployed and unappreciated as a programmer, I look at what they do all day and feel thankful that I get paid to listen to some tunes, crank out a few lines of code and go home (where the real work begins).

The senior technical contact at my day job is a very experienced and accomplished programmer; however his entire day is spent traveling from one location to the next in meeting after meeting (a familiar story for many, I'm sure).

He dabbles in our project from time to time, and I think that's his only release from the mutual appreciation rituals he endures every day.

<comment><AUTHOR> I always thought management looked like a job I'd hate. Now I'm completely sure.

</comment></comment><comment><USER3> Paul Graham's take on it: <http://www.paulgraham.com/makersschedule.html>

</comment><comment><USER4> If this is of interest to you, it's worth reading Peter Drucker, who makes a much more solid, well argued, nuanced case for these sorts of ideas.</comment>