Google's authentication-less, on-the-fly image resizing service - <AUTHOR> https://carlo.zottmann.org/2013/04/14/google-image-resizer/ <comment><USER2> The strange p.txt name clearly indicates this was not designed for use as a public API. Whether they care if you use it is a different issue. My last project is still paying Amazon for each image conversion (Please don't say I should have used imagemagick, I had my reasons.)</comment>


Incident (gTar) looking for a web developer - <AUTHOR>

Web Developer Design District, San Francisco
http://www.incidentgtar.com
Incident is building a unified music platform to make music easier and more accessible for everyone. Our first product, the gTar, is a real-time fully  digital guitar with a multi-touch interactive LED lit fretboard.  The gTar can be connected to a host device such as an iPhone or Desktop computer via USB-MIDI. Our first iPhone app focuses on giving everyone the ability to play music regardless of previous experience through the use of the interactive fretboard display. However, the sky's the limit with what can be done with such a platform, be it music creation, collaboration, entertainment, or education.
That's where you come in.  We're looking for someone passionate about changing music for the better using technology.  Specifically, we're looking for someone to help support and grow the existing platform, as well as design and implement browser based music applications for the gTar and the future devices we're looking to build.
Key Responsibilities
- Implement high-end JavaScript front-end applications using modern techniques - Maintain and build our back-end platform and API - Design and implement new browser-based applications and platform services - Optimize the backend of existing features for performance and stability
Required Skills - CS degree or equivalent - Strong engineering background - Front-end experience in Javascript - Back-end expereince in PHP, MySQL, or equivalent technologies
- Deep understanding of software development fundamentals
Bonus - Experience with the HTML5 Web Audio API - Understanding or experience of existing music production software (Ableton preferred)
To apply, please submit your resume and optional cover letter in PDF or link format to firstname.lastname@example.com.  A portfolio or links to personal project or past work a plus. <comment><USER2> Please wait for the monthly "Who is hiring" thread: <http://news.ycombinator.com/user?id=whoishiring>.</comment>


Drone carrying drugs, hacksaw blades crashes at Oklahoma prison - <AUTHOR> http://www.reuters.com/article/2015/10/27/us-oklahoma-prison-idUSKCN0SL22220151027 <comment><USER2> > in what the officials said was the first attempt in the state to smuggle > material into a prison with an unmanned aerial vehicle

Eh.. surely it's the first _detected_ attempt?!

<comment><USER3> There have been others, at least one last year. I don't know why they say this is the first.

<comment><USER4> In Oklahoma? They clearly say it is the first _in the state_.

</comment></comment></comment><comment><USER5> Perhaps someone should fork this behavior and start dropping care packages for prisoners. Good chocolate. Textbooks, self help books, poetry and literature. Letters from family members. Comfortable underwear. Assistance for those soon to be released. A kind rebellion against the unblinking barbed wire.

<comment><USER6> I think there are legal ways of getting all of these inside the walls of a prison.

<comment><USER5> Which is prob just as fun and pleasant of an experience as delivery by drone.

</comment></comment></comment><comment><USER7> Unless I'm missing something important, it takes some special level of incompetence to fail like that. I have 1 hour and 10 minutes of total flight time of a quadcopter under my belt and could probably navigate better than that.

Which makes me wonder, given the other apparently trivial failures mentioned in the article, how many more drone drops are successful and go unnoticed?

<comment><USER6> It says the stuff was attached by fishing line. I imagine the pilot was trying to keep the drone as low as possible and misjudged the clearance of the fishing line from the top of the fence. Once it was caught, there's nothing you can really do.

</comment></comment><comment><USER8> It's only a matter of time before someone uses a bigger drone to get _out_.

<comment><USER9> Have you seen any of the drones able to lift a human? Absolutely no way that's sneaking around undetected unless the prison is uber incompetent.

<comment><USER10> Doesn't need to be undetected, just fast enough that the escapee doesn't get shot and slow enough that the escapee doesn't die from the G-forces. There's a lot of room between those two extremes. You'd have to install drone guns to protect against the escape drones, but are invulnerable to attacking drone guns. This could get ugly.

</comment></comment></comment><comment><USER11> I know what all the other stuff would be useful for, but does anyone know why it was carrying super-glue? I find it hard to believe an inmate would huff that if they had access to anything else in that package.

<comment><USER12> This is just speculation on my part, but a glue such as cyanoacrylate would be extremely useful for attaching a handle to an improvised tool or weapon.

<comment><USER11> I guess it's lighter than duct-tape and concealable too. I know the hacksaw blades would be useless as anything but weapons, so it's probable that there's an inmate who's now stuck with a surplus of handles and no blades. Worse yet, he could also have a bunch of late drug orders.

</comment></comment></comment><comment><USER13> Sounds like trade goods. If you're escaping (hacksaw blades) why do you need drugs _now_ (leaving soon)?

<comment><USER14> I assumed the hacksaw blades were also trade goods to be used for making weapons. I imagine if you were really determined to escape you may need more materials than that.</comment></comment>


Verisign wants power to shut sites down upon law enforcement request - <AUTHOR> http://arstechnica.com/business/news/2011/10/verisign-wants-power-to-scan-sites-for-malware-and-shut-them-down.ars <comment><USER2> "Well if ICE can do that, why can't we?"

Someone should head down to their local branch of the Occupy Wall Street gathering to see if they can convince some people to add this to their list of grievances.

</comment><comment><USER3> So, how long until amazonaws.com gets shut down?

 _Boom!_ There' goes maybe 70% of the internet startups in one misguided "think of the children" swoop...

<comment><USER4> I think VeriSign is smarter than that. The opposite is more likely: EC2 is "too big to seize".

But startups should be using their own domains, so I'm not sure this is even an issue.

<comment><USER3> I bet there were people who thought DigiNotar were smarter then they were shown to be too...

I do though suspect that Jeff Bezos could throw enough weight around to resolve that sort of problem. (Could Amazon just buy VeriSign outright if they needed too?)

</comment></comment></comment><comment><USER5> The only way this will be avoided is if energy is not wasted on Verisign and instead is directed toward now allowing the police to make the request without a warrant.

<comment><USER5> oops, that should be "not"

</comment></comment><comment><USER6> Anonymous, Where are you?

</comment><comment><USER7> wait they want to shut down 2600 again?

for those that do not know the back story ..2600 the underground hacker magazine site was shut down for awhile because Verizon did not like 2600 giving voice to wikileaks volunteers and een interviewing them..

Verizon kept claiming equipment malfunctions..

</comment><comment><USER8> Either we'll have distributed DNS, or within 10 years the Internet isn't going to exist in a recognizable form.

<comment><USER9> It does look like the US becomes scarier every day. More and more extrajudicial powers, secret laws, restrictions on speech, unwarranted searches/wiretaps and so on. Their "war on freedom" is very successful.

As I've said before, the internet really should stop relying on the US that much. Too bad Europe and others seem to be asleep in this case. Maybe they will get it when it is too late. Having what is slowly becoming the world's only information distribution network in the hands of one government (or, any government) is a very big risk.

<comment><USER8> Sadly, I think placing 'it' in the hands of an international body like the UN or whatever wouldn't be any better. In the case of the UN, it would probably be worse (China and the US would likely veto any measure aimed at opening things up, and with more political cover to do so).

The only long-term solution that I can see if you're really interested in online freedom is to remove all the underlying infrastructure from centralized control in an irreversible way, up to the hardware level as much as is practicable (global wi-fi is probably not realistic but is a goal worth striving toward).

I suppose Tor is as good a model as any, just less visible to an end-user. It isn't enough though, and is still vulnerable.

<comment><USER9> Well, yes. The ideal situation would be to decentralize everything. Tor-like over networks could play a role in that.

But my main point is that so much is hosted on US-based (or US-owned) "cloud servers". And so much relies on US-based services like Skype, Facebook, Gmail. So that when the they pull the internet switch, for whatever reason, the whole communications infrastructure is messed up. And they can easily spy in information stored on their soil.

More and more information and communication is under control by the US. I'm having a hard seeing how we can 'pull out' of this when it becomes necessarily. I don't think we such a reliance on China.</comment></comment></comment></comment>


Hyperdom: A react like framework with (gasp) 2 way data binding - <AUTHOR> http://paul.anmo.io/getting-started-with-hyperdom <comment><USER2> Personally not a huge fan of two-way binding. As someone who has come from the C#/XAML world (where two-way binding can be abused), I found the pure- functional component strategy for React and similar frameworks to be far, far simpler.

Now, I do agree that it can lead to a bit of boilerplate, but this extra verbosity helps keep a simple mental model for us to reason about. Two-way binding can get very complex when you can have weird cyclical state changes.

<comment><USER3> I think weird cyclical state changes are a feature of your chosen framework. For instance I worked on an angular (1.x) project where we would routinely have these issues - in fact they were well documented. We ported the project to hyperdom and I've never seen an issue with state since.</comment></comment>


3D cartoon face and cat face from one image - <AUTHOR> http://www.robots.ox.ac.uk/~vgg/blog/unsupervised-learning-of-probably-symmetric-deformable-3d-objects-from-images-in-the-wild.html <comment><USER2> Tech is in the uncanny valley.

What makes this especially disturbing is that pupils are sticking out in almost all the examples.

</comment><comment><USER3> That fits a bit. My nephew today told me, he would like a game, where he can draw a racecar (2D) and then be able to drive the car in the game. Sadly the demo is for faces only, otherwise I might have hacked something together to make it work ...

<comment><USER4> > _where he can draw a racecar (2D) and then be able to drive the car in the > game_

If your nephew just would draw outlined 2D car side view, then its would be easy to convert it to 3D by extruding and in one two clicks export to supported format for game.

Just two apps needed: _Inkscape_ \+ _Blender_

P.S.: If your nephew no need to play 3D game and top-view racing game (such as _DustRacing2D_ [0]) is enough, possibly only Inkscape would be needed to draw top view of racingcar for game.

[0] [https://github.com/juzzlin/DustRacing2D](https://github.com/juzzlin/DustRacing2D)

<comment><USER3> Yeah, I know, but his car designs usually also involve the front (it is all about the gimmicks, fire and razors and I don't know what else). So a neuronal network would definitely not be able to make a perfect model out of it, but maybe enough to have a somewhat blurry version in tux cart for example.

But I will teach him blender soon, so we will get there eventually, but doing it automated, would be very cool, too ;)

[https://supertuxkart.net/Legacy:Kart_Creation_Tutorial](https://supertuxkart.net/Legacy:Kart_Creation_Tutorial)

but doing this with a automated version, will be hard ...

</comment></comment></comment><comment><USER5> If you pick a cat face and turn it sideways, you can notice that the eyeball isn't at all naturally rounded.

They should be spheres that stick out: [http://images5.fanpop.com/image/photos/28300000/Cat-Eye- Wall...](http://images5.fanpop.com/image/photos/28300000/Cat-Eye-Wallpaper- eyes-28331369-1680-1050.jpg)

</comment><comment><USER6> I can't get this to do anything. It suggests choosing an example, but the list of examples is empty.

<comment><USER7> Works for me in Chrome Linux. Try another browser?

There is a video demo further down the page which is much more informative than the demo IMO.

</comment></comment><comment><USER8> I've seen a system that was more rules based that did this based on a set of sampled head shapes and then you could fine tune the results by hand. One thing that I noticed is that creating a mappable texture from a photo and mapping it onto any reasonable 3D head model was already cool. In any case, this particular attempt doesn't look better than previous techniques I have seen. Every single head in this demo had a pronounced sloping forehead which surely can't be the case for every input.

</comment><comment><USER9> The TL;DR on how it works:

> we exploit the fact that many object categories have a bilateral symmetry. > Assuming an object is perfectly symmetric, one can obtain a virtual second > view of it by simply mirroring the image and perform 3D reconstruction using > stereo geometry

That is pretty brilliant!

<comment><USER10> it says stereo so you need two pictures? I was thinking about the photogramemtry technique, this is great... I mean I wonder how accurate it is(with regard to depth calculation from images on a larger scale like feet) but man impressive

<comment><USER9> > you need two pictures

No, that's the brilliant part. They use one image and apply the assumption that it's a picture of a bilaterally-symmetric physical object in order to produce a synthetic second image.

<comment><USER10> hmm probably have to watch the video more thoroughly it seems like you're estimating/guessing the actual dimensions without a new source/angle to compare for the depth aspect. showing my ignorance here -- trained, I guess it depends on margin of error/does it matter, it seems pretty accurate

anyway this would be great with regard to reducing camera count if you're not relying heavily on LIDAR or "physical time to flight" sources of measurement

</comment></comment></comment></comment><comment><USER11> I find it interesting that if you flip the image around it looks like it's 'sticking out'.

<comment><USER12> I wanted to comment exactly this. The hollow face illusion

[https://en.m.wikipedia.org/wiki/Hollow- Face_illusion?wprov=s...](https://en.m.wikipedia.org/wiki/Hollow- Face_illusion?wprov=sfla1)

<comment><USER13> And interestingly, not everyone sees the illusion: [https://www.ncbi.nlm.nih.gov/pubmed/27847925](https://www.ncbi.nlm.nih.gov/pubmed/27847925)

</comment></comment></comment><comment><AUTHOR> Code: [https://github.com/elliottwu/unsup3d](https://github.com/elliottwu/unsup3d)

Video: [https://www.youtube.com/watch?v=5rPJyrU- WE4](https://www.youtube.com/watch?v=5rPJyrU-WE4)

</comment><comment><USER14> Previous discussion: [https://news.ycombinator.com/item?id=22685053](https://news.ycombinator.com/item?id=22685053)

</comment><comment><USER15> Their visual results are very impressive. But their speech synthesis seems like 20th century quality.

</comment><comment><USER16> What it is also able to do: render cartoon personalities into more real looking personalities.

<comment><USER17> I was very disappointed that Naruto's scrappy good looks didn't make the 2D to 3D jump

</comment></comment><comment><USER18> No https? :-(</comment>


Looking for the Slow Build in the Million Song Dataset - <AUTHOR> http://musicmachinery.com/2011/09/18/looking-for-the-slow-build/

<comment><USER2> Interesting approach but a lot of songs I would consider falling into this category score very low:

Here are a few examples from the original reddit post[1]:

      Song (Correlation)

      The Velvet Underground - Heroin (2.95)
      The Beatles - A Day In The Life (0.00)

Other songs with low correlation:

      Lynyrd Skynyrd - Free Bird (0.38)
      Metallica - Hero Of The Day (3.72), One(3.47)

I think the reason is that tempo and compression (which I associate with tension) are not taken into account but play a big part in our hearing experience. This data may be harder to extract, though. Anyway interesting work!

[1]: [http://www.reddit.com/r/Music/comments/hnc3b/what_is_your_fa...](http://www.reddit.com/r/Music/comments/hnc3b/what_is_your_favorite_song_that_builds/)

</comment><comment><USER3> Others come to mind:

Ravel's Bolero has a "huge build" at least in some versions: <http://labs.echonest.com/loud/?songId=SOKNXIQ13134384E1B>

Metallica's To Live Is to Die actually has quite a quick build [http://labs.echonest.com/loud/?artist=&title=to+live+is+...](http://labs.echonest.com/loud/?artist=&title=to+live+is+to+die)

Godspeed you! Black Emperor's works are more ebb and flow than sustained build throughout the track <http://labs.echonest.com/loud/?songId=SOJBUTX1311AFDAC27>

</comment><comment><USER4> I find this truly amazing, not because of the technologies involved, but mostly because I find it fascinating that we can now easily process a library of over a million song and find which have a "slow build".

</comment><comment><USER5> This is very cool - one quibble though, there doesn't seem to be any test of 'slow' in the slow build. You could add a linear regression slope and select for songs where Pearson coefficient is high, the slope is small and the last decile volume/first decile volume is high is large.</comment>


5 Things We Have Forgotten About Open Source - <AUTHOR> http://jordi.inversethought.com/blog/5-things-we-have-forgotten-about-open-source/ <comment><AUTHOR> People seem to think otherwise, but as the article mentions, the term Open Source was coined by the OSI and you can prove this easily: [https://books.google.com/ngrams/graph?content=open+source&ca...](https://books.google.com/ngrams/graph?content=open+source&case_insensitive=on&year_start=1990&year_end=2008&corpus=15&smoothing=0&share=&direct_url=t4%3B%2Copen%20source%3B%2Cc0%3B%2Cs0%3B%3BOpen%20Source%3B%2Cc0%3B%3Bopen%20source%3B%2Cc0%3B%3BOpen%20source%3B%2Cc0)

<comment><USER2> There is a mostly unrelated use of the term in the intelligence community, but I have no idea the timeline.

</comment></comment><comment><USER3> Here's just one pre-1998 use of the term "open source software", by Bill Joy, at 13:50 in this 1985 interview of/report about Bill Joy, Sun and Unix 4.2 on the Computer Chronicles:

"As for the future of Unix, he [Bill Joy] says its open source code, versatility and ability to work on a variety of machines means it will be popular with scientists and engineers for some time."

It's on youtube under the title, "The Computer Chronicles: UNIX (1985).

Maybe someday Google searches will include all transcripts of all videos relevant to our searches.

<comment><USER4> Thanks, I honestly looked high and low for anyone calling software "open source" before 1998. Your example is the only one I know of so far. I asked esr, who said there were some stray mentions here and there, but he couldn't recall anyone particularly who used the term. I also asked Bruce Perens and Stallman, but none of them could think of anything that was called "open source" before 1998. So, despite this one-off use of the term in this video, it seems nevertheless true that the term was not at all in widespread use nor widely understood.

It is also true that besides "open source" there were other ways to refer to the software, although it was generally considered mostly unremarkable to have source code available, because it was just the natural state of affairs to be able to look at source code. It was only when this natural state changed that people started to insist on consistent terminology for free software and open source.</comment></comment>


Palm's Ares IDE builds on bespin - <AUTHOR> http://ares.palm.com/Ares/about.html First step in web application development, web based IDE! <comment><AUTHOR> I am surprized that more developers are not excited about webos. It frees developers from the App store hindrances. What's really needed is a web app to allow app developers to buy/sell/upgrade app licenses. (If the assumption is that not all app developers are interested in maintaining e-commerce infrastructure)

Also, from a users POV, I found the webos interface to be better than iphone or andriod. IMO, its more than an iterative step in interface design.

<comment><USER2> I like everything they're doing; I just don't trust their capability to win enough market share to make developing on their platform meaningful. Plus, I don't own one so I wouldn't dogfood.

<comment><USER3> On the other hand, while there are fewer WebOS devices out there, there's a massive shortage of Palm apps. You could make an extremely sound business porting successful iPhone apps to the Pre. You'd have huge mindshare if you launched there, first, too.

All in all, working on the development environment is a great play by palm.

</comment></comment></comment><comment><USER4> I quote: "first mobile development environment hosted entirely in a browser, lowering the barrier for web developers to jump into mobile development."

How do you like that, web devs? Now that's a smashing way to begin a relationship!

</comment><comment><USER5> Seems to me that possibly webOS is the superior technology that is almost destined to fail to slightly worse technology like the apple app store etc...</comment>


Progressive Locks: fast, upgradable read/write locks - <AUTHOR> http://wtarreau.blogspot.com/2018/02/progressive-locks-fast-upgradable.html <comment><USER2> This looks quite interesting.

I was looking into implementing something like that (though only R>W) for a caching backend to improve throughput.

</comment><comment><USER3> I wonder whether it could be made to work with futexes in the blocking case.

</comment><comment><USER4> I wonder how these locks work with C11 memory model.</comment>


Show HN: Json2graphql – From a JSON file to Postgres-backed realtime GraphQL - <AUTHOR> https://github.com/hasura/graphql-engine/tree/master/community/tools/json2graphql <comment><USER2> I've tried Hasura and really liked it, but there were a few quirks that led me to another tool, but in general, the whole idea that tools like Hasura, PostgREST, pREST and PostGraphile are trying to solve are the future.

Server side frameworks are obsolete. ORMs are decrepit meta-models and log hewing busywork. Mapping an already powerful model onto one that is less powerful, eating gigabytes of ram to run JVM/Python stacks, countless rolling and restarting of processes. So many hand-rolled loops of code that could just be joins. Multiple queries to smash together two datum that could just be views all in so many thousands of lines of pointless code.

Postgres is already object-oriented, and has been for decades. It already speaks JSON and has for almost 10 years now. It can speak a number of languages, including Python and Javascript, right in the database. Postgres not only stores your data, it _knows_ your data, the statistical distribution and selectivity of queries. No ORM system maintains this kind of optimization state when they generate SQL.

The real power of tools like Hasura is that they get out of the way. They encourage the use of views, functions, extensions, all the powerful stuff that's native to Postgres.

Who cares if it runs on MySQL? The idea is so simple that MySQL can have its own version that gets out of the way and leverages the core power of MySQL. The idea is not to have more frameworks, but to have fewer.

<comment><USER3> Can you share what tool was the final choice and what were the quirks that influenced your decision?

</comment></comment><comment><USER4> Hasura is a boon to productivity and keeps gaining very useful features. I really wish they had a hosted version (like netlify); I don't want to manage servers.

<comment><USER4> This looks setup pretty compelling, but it would still be nice to have an easy to use abstraction on top of it:

[https://dev.to/lineup-ninja/deploying-hasura-on-aws-with- far...](https://dev.to/lineup-ninja/deploying-hasura-on-aws-with-fargate-rds- and-terraform-4gk7)

</comment></comment><comment><USER5> I was excited to see graphql-engine, but unfortunately the AGPL is a bit hard to pitch to folks in an enterprise software context.

<comment><USER6> Hey, I'm from Hasura.

Out of curiosity, did you face trouble trying to get something like Mongo running in the same enterprise context? Especially back when they were AGPL?

We've put up an explanation reg. our AGPL licens here: [https://github.com/hasura/graphql-engine/wiki/License- Explai...](https://github.com/hasura/graphql-engine/wiki/License-Explained)

<comment><USER7> AGPL is pretty much a non-starter for us. It's simply viewed as too risky a license. Thanks to jacues_chester for pointing out the license. The project sounds super cool but there is simply no point in my looking into it on account of that licensing decision. You're shaking my confidence in your decision making, Hasura.

<comment><USER8> (I am not from Hasura.)

AGPL only makes a difference if you link that program and your own code together into one executable (including through dynamic linking). If you're calling from another executable over an API then it makes no practical difference whether it's AGPL, regular GPL or even BSD-style. This is, by definition, a remote API so you'd really have to make an effort to infect your code with the licence.

Just saying "it's too risky" sounds like ignorance. Like if I refused to compile my code with GCC because I heard GCC has a GPL licence. There's not much that vendors can do to counter an attitude like that.

<comment><USER9> Are you a lawyer? A great deal many lawyers have reviewed the AGPL and labeled it too risky for their companies. While I tend to agree with your interpretation of it, I still am extra cautious and avoid AGPL software when I can for infrastructure products like this. I am cautious because of the lawyers opinions on it, and I am also cautious because many companies that adopt an AGPL license turn out to be not very good open source stewards, and they put up roadblocks to community contributions that weaken the project and make having a real open source community behind the projects nearly impossible. There are some exceptions, but they are rare, so I exercise extreme caution around AGPL licensed products.

</comment></comment></comment></comment></comment><comment><USER10> Is there some way to make data available to specific users, but unavailable to others? Basically enforcing an ACL or similar?

<comment><USER6> Yep! Hasura allows you to configure access control rules which are namespaced by "roles" that you can attach to your tables.

Each permission rule can reference a session variable that comes in from your authentication system (whatever it is).

Docs: [https://docs.hasura.io/1.0/graphql/manual/auth/index.html](https://docs.hasura.io/1.0/graphql/manual/auth/index.html)

Examples: [https://docs.hasura.io/1.0/graphql/manual/auth/common- roles-...](https://docs.hasura.io/1.0/graphql/manual/auth/common-roles-auth- examples.html)

</comment></comment><comment><USER11> This is awesome but how do you deal with circular references?

<comment><AUTHOR> It works with circular references. For example, this works:

      {
        "user": [
              { "id": 456, "name": "Sita K", "user_id": 123 },
              { "id": 123, "name": "John Doe", "user_id": 123  }
        ]
      }

Do you have anything else in mind?

PS: Co-author here

<comment><USER12> But then to go from user 456 to user 123 via the field user_id do I have to do a linear search of all users to check their IDs?

<comment><AUTHOR> No. The tool also creates relationships based on foreign key references using Hasura. So to query all the users with the child users, you would make a GraphQL query like:

      query {
        user {
          id
          name
          childUser: userByUserId {
            id
            name
          }
        }
      }

The response would be:

      {
        "data": {
          "user": [
            {
              "id": 123,
              "name": "John Doe",
              "childUser": {
                "id": 123,
                "name": "John Doe"
              }
            },
            {
              "id": 456,
              "name": "Sita K",
              "childUser": {
                "id": 123,
                "name": "John Doe"
              }
            }
          ]
        }
      }

Did I answer your question?

<comment><USER12> Those child users don't then have their own child users (because it's cyclic) so do you have to choose one option of the two, both with a drawback?

I was thinking you could replace or supplement the real user IDs with their indices in the array of returned users.

<comment><AUTHOR> I am sorry, but if possible, could you elaborate @chrisseaton? (preferably with a bit more punctuation :D)

<comment><USER12> With more punctuation? What's that supposed to mean? I've written two short sentences. It's not some wall of text.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> For other related automatic GraphQL tools that create realtime subscriptions to queries, check out [https://github.com/brysgo/graphql- gun](https://github.com/brysgo/graphql-gun)

I'm curious though, with Postgres, how does the realtime aspect work?

</comment><comment><USER14> Is your code heavily dependent on Postgres or it works with any SQL store ?

<comment><USER6> (I'm from Hasura)

Well, today it is fairly dependent on postgres, but we can add more SQL backends eventually. We also leverage some neat Postgres performance tricks which would have to change depending on the database.

Do you have a database in mind?

Hasura is structured as a compiler that takes GraphQL queries, adds access control rules configured by the user and then generates a SQL query. Adding more SQL backends is supporting more SQL dialects.

<comment><USER15> I'm exploring GraphQL for a legacy MySQL database right now and the only option I can see is based on Sequelize, which we don't use.

I'd love MySQL support!

<comment><USER6> Noted!

Not sure if this will help, but one of our users mentioned using symmetricds [1] to sync data from sql-server to postgres and then using Hasura.

[1] [https://www.symmetricds.org/](https://www.symmetricds.org/)</comment></comment></comment></comment>


Feathers came first, then birds - <AUTHOR> https://phys.org/news/2019-06-feathers-birds.html <comment><USER2> Kind of obvious, of course.

For a while there was a "Birds Came First" insurgency, insisting birds were not in Dinosauria because ... well, because they liked birds but hated dinosaurs? The argument never made sense, and it finally died down.

People who like birds and hate dinosaurs are like people who like tetrapods and hate fish. It's allowed, but not something for vertebrate biologists to pay attention to.

</comment><comment><USER3> _PBS 's Eons_ is a great Youtube channel that covered the evolution of feathers.

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

</comment><comment><USER4> I thought that this was known already? But I guess that this is the _Feathers Could be First (2019)_ version.

</comment><comment><USER5> So, this settles it. The egg comes first.

<comment><USER6> It's always been the egg. The egg is laid by a proto-chicken and has the genetic mutation required to tip it into the "chicken" classification.

<comment><USER7> Is a chicken-egg an egg laid by a chicken or an egg that yields a chicken?

<comment><USER8> Nice try - but the original question doesn't state the egg has to be a chicken-egg, just "the egg".

<comment><USER9> But a bird's heavier than feathers.

<comment><USER10> But when birds of a feather flock together, many hands make light work.

<comment><USER11> And it's known that a bird in many hands is just a gross bunch of fleshy bits with feathers sticking out.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Seriously though, I have done a bunch of "wikipedia research" on how flight evolved. It's all a bunch of "just so" stories and theories, which struggle to prove any evolutionary advantage to intermediate forms that can't achieve flight or even gliding.

I think the evolution of flight is one of the clearest examples that the standard theories of evolution purely by mutation and natural selection are still lacking explanatory power. I understand that the theory of Common Descent has ample evidence but let's not conflate that with the other theories (about HOW genetic drift happens in macroevolution) and turn "evolution" into a religion in our quest to replace creationist accounts. It is a catch-all umbrella term to describe many theories, from "punctuated equilibria" to the "modern synthesis", which still are in their infancy as the luminiferous aether or phlogiston as physical theories.

I find there is too much suppression of dissenting views in evolutionary and climate science, for my taste. I am talking about universities and publishers taking concerted _political_ action against what is perceived as going against the current establishment.

 _A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it._ \- Max Planck

In many circles, publishing anything critical on scientific grounds is like publicly criticizing capitalism in USA or Islam in Saudi Arabia. A lot of time you get instant downvotes and hostile responses from laypeople.

If you're curious what I'm talking about, here is probably one of the better treatments of the mathematics behind current theories, for example: [https://www.amazon.com/dp/1880582244/ref=cm_sw_r_cp_api_i_r....](https://www.amazon.com/dp/1880582244/ref=cm_sw_r_cp_api_i_r.M9CbRRG16AF)

<comment> 1e-9 I think it is quite plausible that feathers originally developed for thermoregulation. If they started as simple filaments that could be raised and lowered to adjust radiative surface area, it seems that thermoregulatory advantages alone could have driven a series of small evolutionary improvements towards flat, light-weight feather-like structures. Seeing a bird able to massively fluff up its feathers or pull them in tight against its body is like seeing a person instantly go from wearing a puffy down coat for winter to a sleek body suit for summer exercise. From there, I can imagine how these flat, controllable surfaces could be used by small animals to eventually control rapid descent from trees to escape prey and then eventually evolving to flight.

<comment><USER12> We can certainly explore that theory, but what can you suggest as falsifiability criteria? Flight evolved several times, presumably, including in insects and in mammals without feathers:

[https://ucmp.berkeley.edu/vertebrates/flight/bats.html](https://ucmp.berkeley.edu/vertebrates/flight/bats.html)

Notice:

 _We can infer that bats gradually evolved true flight from a gliding arboreal ancestor, possibly using the gliding membrane as a sort of "net" while the flight stroke evolved._

We can infer this because we beg the question, _i.e._ the only way evolution can happen is random mutation and natural selection. And so, we postulate the theory as true fact and then we get the result that it _must have happened some way_ that is consistent with the theory.

I am just generally remarking on the fact that _all that seems to be required_ in today's scientific environment is to _describe what could have happened_ with some arboreal ancestor gaining, say, webbed wing-like arms for some reason, and then over thousands and millions of generations for some reason, before the webbed arms could help them glide, they were accepted instead of shunned by their mates for their mutation, and the mutant population survived and genetically drifted in that direction, until finally they could glide... and then fly.

<comment><USER13> It could be falsified by finding fossil evidence of ancestors that had no flight yet, did have feathers, but had some other mechanism of thermoregulation sufficient for their needs.

The fossil record is incredibly limited and I'd bet against such a fossil ever being found even if the animal existed, but in principle it is a falsifiable theory.

<comment><USER12> Well in principle string theory is falsifiable too. But at least string theory has a lot of math that always seem to work out. Here we have _a bunch of stories_ and a lot of politics.

When the stories don't even make consistent sense (eg how do exclusively gay or asexual people exist if many theories of evolution predict such a trait would have been practically weeded out of the population by now, but it keeps coming back) people grasp at straws to say "well it HAS TO have SOME fitness advantage" because they just stick to the same basic theoretical framework no matter what the data says.

<comment><USER13> Does evolution even predict that it would have been practically weeded out? As far as I know we don't even know what causes people to be gay.

Some things can't be weeded out by evolution, e.g. we will never lose major traits that are developed in the first weeks of an embryo's development, as everything that develops in the later stages depend on the first.

Non-hereditary traits aren't obviously weeded out either, and I don't think homosexuality is (always) hereditary.

Has there really been any research by evolutionist biologists suggesting that homosexuality should have been weeded out and it's an anomaly in our theories?

<comment><USER14> > As far as I know we don't even know what causes people to be gay.

We don't know what causes people to be straight either, but that doesn't seem to stop evolutionary biologists proposing evolutionary explanations for the existence of straight sexual desire.</comment></comment></comment></comment></comment></comment></comment>


Contrarian view on closing files - <AUTHOR> https://coady.github.io/posts/closing-files/ <comment><USER2> Horrendous advice on many levels

\- reference counting is an implementation detail, it is not part of the spec

\- that's because real implementations exist where refcounting does not exist (ironpython, pypy, jython)

\- even if it were part of the spec, the schedule for object destruction also is not part of the spec. Your file object was noticed as part of an unused graph at T+0, even mainline CPython can perpetually defer its destruction to T+infinity due to its handling of reference cycles

\- the random system resource will eventually be garbage collected, but perhaps not if your code throws the wrong exception and/or one of those cute syntax sugar libraries takes a reference to its frame object you know nothing about. Or how about pretty much any debugging support library like Sentry? Best to have audited them all..

\- the random system resource was garbage a few tens of opcodes ago, but you left it locked, and some future change caused your code to immediately attempt to reopen and relock it. surprise, deadlock in production

The comparison with 'dict.clear()' makes no sense whatsoever because explicit external resource control is _precisely_ required because those external resources aren't automatically managed like normal in-memory objects. They have material external state beyond whether they are allocated or deallocated, and require explicit initialization and de-initialization in order to avoid leaving them in unspecified states. Python's memory allocator provides none of these behaviours as guarantees. It's not even guaranteed to always call __del__, this is most commonly observable during interpreter shutdown.

Perhaps a better way of looking at it is this: try/finally and with: exist for you to demand stronger guarantees from the runtime than it normally offers you. "Hey Mr. Python, I know you'll /probably/ clean up this object eventually, but I also know there are 100 edge cases where you won't bother. For this object, you are on the hook for every case, including the cases where I wrote buggy code"

Meanwhile, feel free to follow this advice, and good luck at 4am debugging your prod system that for some inexplicable reason recently began crashing due to running out of file descriptors..

<comment><USER3> > \- reference counting is an implementation detail, it is not part of the > spec

> \- that's because real implementations exist where refcounting does not > exist (ironpython, pypy, jython)

Exactly. That was a major if not _the_ major drive for context managers & properly closing files: the PFS and the language team were getting much more supportive of third-party implementations, and much more aware of issues in "normal" Python code e.g. though it didn't work out well in the end, ctypes also got merged into the stdlib in 2.5 with the express purpose of limiting the need for writing cpython extensions to bind to native libraries.

> \- the random system resource will eventually be garbage collected

Not necessarily! In fact this is one of the major problems for non-memory resources in GC'd languages: the GC is triggered by memory pressure and that's it. Because it knows nothing about fd pressure, if fd consumption is not matched by enough memory consumption (or a properly matching pattern thereof) it's rather possible to keep leaking fds without the GC ever running (or ever running a collection which reclaims your file objects).

For instance, back then trying to _install_ some packages would crash under pypy due to file exhaustion, because setuptools leaked fds all over the place: [https://bitbucket.org/pypy/pypy/issues/878](https://bitbucket.org/pypy/pypy/issues/878)

The stdlib also did: [https://bugs.python.org/issue13133](https://bugs.python.org/issue13133)

<comment><USER4> >the GC is triggered by memory pressure and that's it. Because it knows nothing about fd pressure,

So why not teach it about fd pressure?

There's no reason not to teach a GC about fd pressure - the reason that's rarely done is that language implementers generally don't care that much about the system interface - they just link against libc and call it done.

<comment><USER5> > You can't even define a custom hashing function

All objects subject to GC have a memory impact, very few of them have an fd impact. You either have to separately track those that impact fds, or do a lot (up to 100%) unnecessary work in response to fd pressure. Even if user code can disable the fd pressure response, you've got to carry the baggage of a GC with extra code to handle it around. It's very easy to see "teaching a GC about fd pressure" as not worth the time and effort for the main runtime GC for a general purpose language. If you had a facility for swapping in special purpose GCs for particular applications, building a specialty GC that added fd awareness might be a net win for some apps, but...

<comment><USER4> >It's very easy to see "teaching a GC about fd pressure" as not worth the time and effort for the main runtime GC for a general purpose language.

Yes, that's what I said:

>language implementers generally don't care that much about the system interface - they just link against libc and call it done.

There's no research done in this area (at least I don't know about any). I'm sure if people cared about it, they would find good solutions. But they mostly don't care about the system interface - which leads to the problems that this article is talking about.

(Not that Python is on the fore-front of CS research - it's downstream of more innovative languages - but if those languages cared and had done research about the system interface, they would have come up with good ideas that might flow down to Python)

</comment></comment></comment></comment></comment><comment><USER6> > But in all seriousness, this advice is applying a notably higher standard of > premature optimization to file descriptors than to any other kind of > resource.

Maybe the same standard should be applied to other kinds of resources. Maybe garbage collection was a mistake.

> It's a violation of procedural abstraction to know whether the result of > load is lazily evaluated or not; it's just supposed to implement an > interface.

Lazily-loaded things are different from eagerly loaded things in important ways. If it's not possible to make that distinction visible in your language, get a better language.

> No, it will not be fixed. This version only appears to work by not closing > the file until the generator is exhausted or collected.

Which is exactly what we wanted. It is fixed.

> Furthermore it demonstrates that often the context is not being managed > locally. If a file object is passed another function, then it's being used > outside of the context. Let's revisit the json version, which works because > the file is fully read. Doesn't a json parser have some expensive parsing to > do after it's read the file? It might even throw an error. And isn't it be > desirable, trivial, and likely that the implementation releases interest in > the file as soon as possible?

Look at iteratees for the full solution to this problem. Managing context can be hard, but it doesn't have to be; you just have to use the right abstractions.

> Those threads are essentially debating whether a resource pool is "leaking" > resources.

If you open a pool and never close it, of course you're leaking everything in that pool.

> if all this orphaned file descriptor paranoia was well-founded, it would > have been a problem back then too.

It was. Long-running python programs broke because they ran out of file descriptors.

</comment><comment><USER7> I'm lost between the no-true-scotsmen and strawmen the post tries to construct.

The advice about closing the descriptors is for practical reasons. There's no need for "true believers" taking that advice to extreme. Just like clearing the dict if you're dropping the reference anyway is useless.

If you can consume the file immediately, you can close it. If you're doing lazy iteration you have to keep it open, and I don't understand why that's an issue.

<comment><USER8> _"If you 're doing lazy iteration you have to keep it open, and I don't understand why that's an issue."_

It isn't an issue if you process a few files that way (unless you're running your system very close to the limit), but it is an issue if you have a long running process that lazily iterates over files often. Examples are iterating over a file system (say a kind of _grep_ ) or a web server where an often called entry point does this.

<comment><USER7> Sure. But I was getting at something different. You can choose your open files limit on one side and the approach (lazy or not) on the other. If you choose lazy there's no way around having to leave the file open.

</comment></comment></comment><comment><USER9> The point of a file context manager is to close the file when you're done with it. The CSV reader isn't done with it.

Given that the CSV reader does not control ownership of the file handle, it shouldn't return a lazy iterator when given a file handle. It should accept a path, then it could own the file handle until the iterator is complete or dropped.

So, yea, the CSV reader does a bad. But so what? That is a deficiency of the CSV library, not context managers.

<comment><USER10> Libraries that accept filepaths (except perhaps as a convenience) are bad. The CSV library is well-designed. It isn't responsible for closing files because it doesn't _take_ files, it takes _TextIO_. None of this is to say context managers are bad; I think they're great but they only work as intended.

<comment><USER11> That's being a little pedantic IMO. From a practical, user-facing perspective, the CSV library Reader takes in files. And they know this, which is why the documentation specifically calls out gotchas related to passing in a file object and the example code shows how it should work with a file object [1].

[1] [https://docs.python.org/3/library/csv.html#csv.reader](https://docs.python.org/3/library/csv.html#csv.reader)

<comment><USER12> File like objects are not necessarily files. A library consuming them can't presume to manage them.

</comment></comment></comment></comment><comment><USER13> > Moreover, according to this best practice, it's _impossible_ to write the > csv version correctly.

Um, just consume the iterator immediately, then it's the same as the json one:

      def load(filepath):
          with open(filepath) as f:
              return list(csv.reader(f))

The equivalent for the latter json example that separates the read and parse would be:

      def load(filepath):
           with open(filepath) as f:
               contents = f.readlines()
           return csv.reader(contents)

<comment><USER14> _> Um, just consume the iterator immediately_

That's fine for some use cases, but TFA wanted a lazy iterator.

<comment><USER15> If you want a lazy iterator, then you will need to keep the file handle open. I don't see how this one use case invalidates the general guideline of not sitting on file descriptors that you are finished with.

<comment><USER16> How you feel about this is key to the article's argument. It makes the point that you shouldn't have to know if the iterator is lazy or not, that's an implementation detail.

That does seem...generally desirable? But given Python already gives you easy and different syntax to create lazy vs greedy iterators, and you often can't use them interchangeably, it's clearly not a top design goal of the language.

<comment><USER17> It sounds desirable, but isn't feasible unless the language is stateless. If you iterate over a thing that is stateful, you need to know whether the iterator is lazy or not to decide if you can modify the underlying thing.

<comment><USER16> I don't think that's right. You can always turn it into a greedy iterable (e.g. convert it to a list) if you need the certainty that you can modify the underlying thing, while still reaping some performance benefits from the maybe-lazy iterator in the rest of your use cases. Assuming the iterator wasn't infinite, of course, but in that case you already knew it was lazy.

<comment><USER17> Right but you have to know the iterator was lazy to know that you need to convert it.

<comment><USER18> Is it really that arduous to have a high-level understanding of what the method you're calling does, at least at the level of knowing whether or not it returns the type of object you want and whether it takes ownership of its arguments?

There's a separate question of whether the standard library should be inconsistent with itself, but it seems like a reasonable choice -- you can't efficiently use a json file without doing _something_ invasive to it like loading it all into ram, but a csv file isn't burdened the same way, and you probably don't want to be limited by available ram when all you need to do is enumerate a csv.

<comment><USER17> I'm not sure what you're arguing for. My point is that you cannot, in general, abstract over both lazy and eager iterators. There are irreconcilable differences in how they work (and how you have to treat them).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> I'd like to emphasize the point even further for CPython users. Here's the author's closing sentence:

>Your setup script is not going to run out of file descriptors because you wrote open("README.md").read().

In CPython, files are closed (if necessary) in __del__, so the descriptor is released immediately after that line executes, thanks to CPython's reference- counting mechanism. That idiom wouldn't cause you to run out of descriptors even in a long program.

(The author knows this. Their point is that even if you're NOT using CPython, you STILL shouldn't worry about it too much, and I think I agree.)

I know, I know, CPython's reference-counting behavior is considered an "implementation detail", but for RAM-intensive workloads which are common in Scientific Computing (especially biological imaging), it's often a necessity. So if I were to force myself to use context managers in cases like this, I'd be losing the benefits of terse code without actually preserving portability. (I didn't have portability in the first place.)

In other words, if you're dependent on ref-counting anyway, you may as well admit it and enjoy the benefits that come with it!

<comment><USER20> It won't be released immediately, that's the point. It will be "released at some point in the future and definitely not during interpreter shutdown".

A "with" statement ensures the release happens deterministically, which it turns out is a desirable trait to have.

<comment><USER19> The Python standard makes no guarantee, but in CPython, the example above is deterministic. The cycle-detecting garbage collector is not involved in this case. Just refcounting.

<comment><USER2> If open() throws an exception, perhaps after the FD is already open (Python does non-trivial IO to a file immediately after open), or read() throws an exception, the file object is at the mercy of any try/except higher in the stack, any bugs/"features" contained in those, and any sys.excepthook installed like Sentry

The example above is deterministic only on current versions of CPython and only if it is guaranteed to succeed and if it is the only line of code in the program now and in perpetuity.

</comment></comment></comment></comment><comment><USER5> > Any resource may be limited or require exclusivity; that's why they're > called resources. Similarly one should always explicitly call dict.clear > when finished with a dict.

I think there is an important distinction between resources for which there may be contention _within_ the process, vs. _external_ resources. It's tractable to provide sufficient certainty that in an internal resource isn't subject to problematic contention either analytically or by testing or a combination, but that's less tractable with external resources. So, use guaranteed freeing of resources (context managers, if possible, in Python) for external resources or for internal resources that you can't otherwise be reasonably sure are free of contention issues.

</comment><comment><USER21> Many good points are made here, but I would point out that there is a significant difference between working with JSON and CSV: data that can be operated on can typically be extracted from a CSV by working iteratively over each line. The same can not be said about JSON files.

It is normal and (almost always ?) required to parse/de-serialize an entire JSON file at once and hold the contents of it in memory, while the same is often impractical and unnecessary for a CSV (when it is millions of lines). The standard methods and idioms of doing these things in Python reflects this.

<comment><USER22> It's not uncommon to see files or streams in "JSON lines" format. For files where each line is a record and the records are sorted or indexed, it's possible to seek to a record of interest just as in CSV.

[http://jsonlines.org/](http://jsonlines.org/)

<comment><USER23> Those files are individual JSON entries though, as per the spec. They're not read as a JSON (since they aren't) they are read per line, and each line is parsed as a JSON.

<comment><USER20> Same as CSV then?

<comment><USER23> Yes, but not the same as JSON. Which was my point.

In other words, collection of JSON strings in a file != a JSON file.

</comment></comment></comment></comment></comment><comment><USER24> > Your setup script is not going to run out of file descriptors because you > wrote open("README.md").read().

How about even simpler (python3)

      Path("readme.md").read_text()

Ta-da. I don't even have to worry about opening files, let alone closing.

<comment><USER25> To complete your comment, let us import pathlib.

      from pathlib import Path
      Path("readme.md").read_text()

The functions read_text and the similar write_text, read_bytes, write_bytes are new in Python 3.5.

[https://docs.python.org/3/library/pathlib.html#pathlib.Path....](https://docs.python.org/3/library/pathlib.html#pathlib.Path.read_text)

<comment><USER26> I wasn't aware of these functions. At first glance, their addition to Python seems to be a significant violation of "one-- and preferably only one --obvious way to do it".

What are the advantages of `read_text` over the traditional `file` read methods?

</comment></comment></comment><comment><USER27> _The csv version returns an iterator over a closed file_

That's why method/function naming is critical and underestimated. Without having worked with python too much:

_json.load()_ is a load: implies the action is done on return. I understand there's nothing to do after it, other than use the return value.

_csv.reader()_ clearly returns an object that it's going to be used to traverse the underlying, so the underlying must remain open. Implies a stateful operation to me.

Besides, examples are clear:

[https://docs.python.org/3.8/library/csv.html#examples](https://docs.python.org/3.8/library/csv.html#examples)

Classical problem of wanting to use The Perfect Abstraction.

</comment><comment><USER28> > But in all seriousness, this advice is applying a notably higher standard of > premature optimization to file descriptors than to any other kind of > resource.

I don't think it's premature, but properly closing files is definitely not about _optimization_. Maybe "a notably higher standard of code quality"?

<comment><USER29> How does it positivity affect code quality?

It seems to me like it would be the opposite, automatic closing means less boilerplate and more expressive code

<comment><USER30> By automatic closing do you mean not at all and expecting the GC to do it? Or with a context manager.

I think trusting an implementation detail of the underlying interpreter is lazy at best and an anti-pattern at worst. We should aim to show our intent as much as possible, and closing a file or using a context manager certainly expresses our intent.

<comment><USER29> I mean imagine a hypothetical language where it was idiomatic to let the GC close files for you and the language was specified in such a way that it was guaranteed to work efficiently and wasn't just an implementation detail.

Would code in that language have lower code quality than code in a language where files have to be closed manually? That's what the other poster seemed to be implying, but I think the opposite is true

<comment><USER28> I don't quite see what you mean by "efficiently". A language where garbage collection of file objects is guaranteed to happen within N milliseconds? The issue is holding on to an external resource for longer than needed. and by definition, garbage collection is deferred cleanup.

<comment><USER29> I mean "efficiently" in the sense that the consequences of having extraneous open file objects are managed appropriately so they don't blow up the system. I don't think that necessarily means collecting them all right away, but that's one option

</comment></comment></comment></comment></comment></comment><comment><USER31> GC advocates say that managing memory lifetimes is an excessive burden to programmers.

Anti-GC advocates say that memory is just one particular instance of management of life-timed resources, and that special casing it is an ugly hack and you should be using RAII. Rust probably is the leading exponent (C++'s way is more of a mess).

The RAII critics point out that RAII also glosses over part of the problem because often de-allocating resources can itself fail (e.g. closing a file) and RAII (in Rust or C++) has no proper way to deal with that.

Then, there is the Reference counting camp, the only people who can say that they solve the something close to the general automatic resource de-allocation problem -- because lifetimes are precisely tracked. But reference counting can't cope with cycles and generally has poor performance. Also, it does not directly help with de-allocation failures. One interesting recent variation are attempts at static reference counting: [http://strlen.com/lobster/](http://strlen.com/lobster/).

Last there are the old and the new muddle through camp. The old muddle through camp (e.g. java, python) adds finalizers with crap semantics (call-me-maybe). The new muddle-through camp uses GC for memory but adds some extra mechanism for other resources (defer in go, <close> in lua 5.4). Defer in go seems like an inferior version of rust-style RAII. Lua 5.4's <close> also has/had problems (see [http://lua- users.org/lists/lua-l/2019-06/msg00179.html](http://lua- users.org/lists/lua-l/2019-06/msg00179.html)).

The author of the article advocates old-style muddling through, but this feels unsatisfactory because it's not robust in general and likely worse than following current "best practice". But it still seems like there is still no really good general solution available. Rust-style ownership tracking would have solved the lifetime ambiguity of the file for the csv reader, but would not be able to deal with file close errors properly. These can be somewhat handled with exception based mechanisms, but not without problems either -- because multiple things can go out of scope at once, requiring cleanup and one or more of these cleanups may fail themselves but try catch statements (with stack unwinding) offer no natural way to deal with multiple failures being propagated up at once.

</comment><comment><USER15> There are lots of reasons to close a file when you are done with it, especially if you are writing to that file. These considerations are not about "pythonicity", but rather about best practices for unix.

</comment><comment><USER32> > The csv version returns an iterator over a closed file. It's a violation of > procedural abstraction to know whether the result of load is lazily > evaluated or not; it's just supposed to implement an interface. Moreover, > according to this best practice, it's impossible to write the csv version > correctly. As absurd as it sounds, it's just an abstraction that can't > exist.

This is simply not true. A load being lazy or not will often be a part of API documentation. In some cases, documentation will include that a .close() needs to be manually called. It's also trivial to read an entire CSV file, close it, and return an array of lines, or a dataframe, or whatever. Of course, you probably don't need to do it with a generator, and it won't be a two-liner (although @Izkata gives a two-liner example). In that implementation, you'd achieve behavior parity with json.loads(...).

> No, it will not be fixed. This version only appears to work by not closing > the file until the generator is exhausted or collected.

I'm no fan of Python (even though I use it every day), but this is extremely well documented in PEP 342[1]. I'm honestly not sure what the complaint is here. I guess the standard Python CSV library is a bit wonky, but that's about it.

[1] [https://legacy.python.org/dev/peps/pep-0342/](https://legacy.python.org/dev/peps/pep-0342/)

</comment><comment><USER33> If you're reading the whole file at once, I'd use `Path().read_text()`.

</comment><comment><USER34> This is to some extent a Python-specific problem. In most languages with destructors, you're guaranteed a destructor call when a local variable's scope is exited. But not Python.

Python isn't RAII, it's an explicit close language. That's what "with" is for. Python's "with" clauses, unusually, play well with exceptions at scope exit. Nested "with" clauses can fault out with a close exception and still have everything unwind properly. Very few languages get that right. Python probably has the most useful exception system around.

Calling destructors from the garbage collector has a whole other set of problems. Suppose you're writing to a network and the network connection fails during close. Now you can be stuck in the garbage collector calling the destructor waiting for the network to time out. I'm not sure how garbage- collected Python implementations handle this. C# can potentially get into that state, too. Anybody know?

Raising an exception in a C++ destructor is usually not happy-making. Microsoft tried to make that work in Managed C++, which has "re-animation". A destructor can pass a reference to its own object outside of the destructor, which "re-animates" the object. Turned out not to be a good idea.

I would have liked to see exceptions in Rust, which has enough static ownership analysis to determine whether a destructor is trying to make something outlive its lifetime. Most of the problems with destructors vs exceptions involve scoping issues. If such errors are caught at compile time, exceptions are better behaved.

<comment><USER35> In most managed-memory languages, try...finally (and using/try-with-resources which are based on it) handle exceptions just fine. The only problem that sometimes occurs is that exceptions thrown by a finally handler override the exception being bubbled, which can be bad if you wanted to handle that exception later on, but otherwise the resources get cleared properly. D has better behavior here, where throwing an exception on this path will automatically keep track of many in-flight exceptions.

Also, the problem of finalizers blocking is partly handled by the fact that finalizers are not run by the GC threads, but by a separate finalizer thread. Still, if a finalizer blocks, eventually you will run out memory, as all objects which require finalization will be pooling up.

Also, the re-animation behavior you describe is common to finalizers in all GC languages which expose them, it's not in any way specific to Managed C++ (C++/CLR). It is simply a consequence of how finalization works: when an object which requires finalization is eligible for GC, it is not collected, but moved to the finalization queue. Objects in that queue are still live objects. When the finalizer thread successfully runs the finalizer of such an object, it is simply removed from the finalization queue. If it's finalizer has added back a reference from some other GC root to the object, then it will still stay live. The only special property is that an object can't be finalized twice, so even if its finalizer attaches it to the live object graph once, when it becomes unreachable again it will be collected, it will not be put back in the finalization queue, it will be directly collected.

Basically, I don't think there is too much chance to find a valid use for this behavior, but it is very hard to prevent it without complicating the language significantly.

<comment><USER36> > Basically, I don't think there is too much chance to find a valid use for > this behavior, but it is very hard to prevent it without complicating the > language significantly.

One approach is to provide a mechanism for cleanup that doesn't require the object to still be alive. Java has phantom references for this:

[https://docs.oracle.com/en/java/javase/11/docs/api/java.base...](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/PhantomReference.html)

[https://stackoverflow.com/a/43659951/116639](https://stackoverflow.com/a/43659951/116639)

And i learn that Smalltalk introduced the "ephemeron", which is now present in some other languages:

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

<comment><USER35> Sure, there are other possible cleanup mechanisms, and I believe Java is depreciating finalizers in favor of those other mechanisms. My point was only about finalizers themselves: a language with the finalizer mechanism I was describing above would need to add a lot of features to prevent finalized objects from becoming reachable again.

</comment></comment></comment></comment><comment><USER37> IMO part of what's happening here is that Python's GC model works well for memory and leaks for other resources.

Rust's ownership model works very well for many non-memory resources IMO, and even for memory it is very safe and efficient, with the only cost being mental overhead at times. Something like Rust's ownership system but with an easy escape hatch for "loose" resource management (ie GC) could solve a lot of the cognitive load with resources, I think. Rc is helpful, but not nearly as ergonomic as a GC language.

I think withoutboats had a similar blog post a year or two ago.

<comment><USER38> I'm not sure it is fair to attribute this to Python's GC model, in that what is commonly thought of as garbage collection is not involved with the issue being discussed.

However, in principle, this issue is very simmilar to that which garbage collectors set out to solve.

In effect, python's context managers combined with the "with" syntax recreate the sementics of C's local variables in that:

1) They can be passed outside the lexical scope in which they were defined but

2) They're usage is illegal after execution has exited the "block" in which they are defined.

3) There is nothing which prevents a programmer from keeping and attempt to use a reference to them after execution has left the code block.

The approach I take in python is the same I take in C. Most of the time, I only need to file for a short period, so I can "stack" allocate it with a context manager and let the runtime handle closing it for me. In cases where stack-like sementic do not fit, you need to use heap-like semantics and manually open/close it.

<comment><USER37> If you're not familiar with Rust, one of the core features is that you can "pass" or "borrow" that stack-like scoping in a safe way. IE, if you create a file handle, it gets automatically cleaned up when the current scope ends… unless you transfer ownership to other code, and then it is cleaned when THAT scope ends. It also prevents references from dangling after the resource has been cleaned, even in other classes or functions.

This lets you model ownership rather than memory, and the compiler will translate that (for the most part) to memory management for you. What I was trying to say is that I think managing ownership as a first-class language feature is more generally useful than trying to abstract away the concern with something like GC.

</comment></comment></comment><comment><USER39> Hmm. I just ran out of file descriptors on a little personal project of mine just a few days ago.

I kept calling pty.openpty() and I forgot to close them. My program was calling it three times (stdout, stderr, stdin) every 10 seconds :(

I ended up writing a context manager for it and now it works well. Unfortunately contextlib.closing() wouldn't work as pty.openpty() returns two objects.

</comment><comment><USER40> As a counterexample: we did actually run out of file descriptors on Lambda by not closing file descriptors.

</comment><comment><USER41> This is like a worse version of javascript semicolons.

Sure you dont HAVE to... but there's gotchas and corner cases to not doing it that you don't have to think about if you close your file desciptors when you're done with them

</comment><comment><USER5> > Moreover, according to this best practice, it's impossible to write the csv > version correctly.

No, it's not:

      def load(filepath):
        """with a different file format"""
          with open(filepath) as file:
              return list(csv.reader(file))

This both uses csv.reader and fulfills the required contract correctly.

Yes, it's tricky to both follow the "assure a resource is closed" pattern and return a lazy iterator over the external resource which you open.

If you are going to lazily iterate over a resource and do the context manager pattern, you have to do the work within the context manager.

</comment><comment><USER42> This is an actual drawback of not having deterministic destruction. This would not be a problem in C++ or Swift.

<comment><USER43> Exactly. Yet Java has autocloseable without having deterministic destruction

<comment><USER3> AutoCloseable is the same as Python's __exit__, it exists as a hook to try- with-resource in the same way __exit__ is a hook for `with`.

</comment></comment></comment><comment><USER44> IMO, the author is looking at the central problem with GC systems: non- deterministic destruction, and unclear ownership.

> _This trivial example has deeper implications. If one accepts this practice, > then one must also accept that storing a file handle anywhere, such as on an > instance, is also disallowed. Unless of course that object then virally > implements it owns context manager, ad infinitum._

Yes, and I just accept that. This happens in C#, too[1]:

> _If your class owns a field or property, and its type implements > IDisposable, the containing class itself should also implement IDisposable. > A class that instantiates an IDisposable implementation and storing it as an > instance member, is also responsible for its cleanup._

And for good reasons; in this regard, the languages are basically identical. I'd say any language that uses GC and instead has some sort of language-based guard system (Python's `with`, C#'s `using`) or even just through convention (e.g., Java, back before try-with-resources) will end up having that happen. Depending on the GC to collect these resources isn't wise, since no behavior on the GC is actually guaranteed.

> _No, it will not be fixed. This version only appears to work by not closing > the file until the generator is exhausted or collected._

I'd call that fixed; the file is properly and deterministically closed, when the generator is exhausted or manually closed. (By calling the generator's `close()` member function.) Now, it is now up to the calling code to remember at every use site to do that, and it should be made an explicit part of the documentation for the interface. But, the same for context managers, or things having a close: it's part of the contract that you will call that .close(), or wrap it in a with block, or the resource leaks until the GC gets to it. (I do wish generators were context managers, to make this easier.)

IME, the bigger problem here is that GC forces, for resources that have a destructor beyond "free the memory" (that is, what the GC itself handles), for each call-site to remember to clean up the resource. Files are one thing, and _generally_ , yes, you'll probably get lucky and not run into issues. Locks are more fun, and often leaving it to the GC to release a lock is a lot more painful. (Then there are threads, child processes, sockets, …) RAII fixes this for _all_ types of resources by bounding the lifetime of the resource to the scope(s) that it lives in.

(And, because it inevitably comes up, IME, people worry too much about cycles; cycles do happen, but are incredibly rare compared to non-memory resources (those that are more than just memory, e.g., files, locks, etc.), and vanishingly rare compared to all resources (those that are more than just memory and those that are just memory, like vectors or strings). Yes, they are an issue of sorts in RAII, but there are ways to handle them. I do not think the bad with cycles outweighs the good of RAII.)

[1]: [https://docs.microsoft.com/en-us/dotnet/standard/garbage- col...](https://docs.microsoft.com/en-us/dotnet/standard/garbage- collection/implementing-dispose#cascade-dispose-calls)

<comment><USER45> It's not a problem with _gc_ in general. Erlang for example you typically don't close files if you know the lifetime of your process is transient, you do, if it's permanent. End of rule.

<comment><USER46> Is that really idiomatic? I don't write much erlang but it seems like that wouldn't work for any code shared between two processes, one transient and one permanent.

<comment><USER45> Why would you share file opening code between two such processes. That sounds like premature abstraction. If you're really doing something in a library like the gp csv example then yeah, close it.

<comment><USER46> Say you write a library which opens a file.

</comment></comment></comment></comment></comment><comment><USER47> Pretty ballsy posting a link to your own blog post on HN on such a controversial topic. Prepare to get smashed in the comments!</comment>


Nassim Nicholas Taleb: "The Intellectual yet Idiot" Class - <AUTHOR> https://medium.com/@nntaleb/the-intellectual-yet-idiot-13211e2d0577#.nn139jr77 <comment><USER2> Interesting characterization of the US voter base:

> _While rich people believe in one tax dollar one vote, more humanistic ones > in one man one vote, Monsanto in one lobbyist one vote, the IYI > [Intellectual Yet Idiot] believes in one Ivy League degree one-vote ..._

</comment><comment><USER3> This guy is peeved about politics and he has a new class of people he wants to blame for it.

His description of this class of people is odd and improbable: some sort of foppish Englishmen who have contrived a way to vote for Hillary Clinton.

Now, there are some things he said that are more generally applicable. Particularly: "Beware the semi-erudite who thinks he is an erudite." I'm pretty sure he just put himself in this class, no matter how hard he tries to deadlift his way out of it.

<comment><USER4> rspeer: "His description of this class of people is odd and improbable: some sort of foppish Englishmen"

You aren't possibly referring to (from the article)

"... that class of paternalistic semi-intellectual experts with some Ivy league, Oxford-Cambridge, or similar label-driven education who are telling the rest of us 1) what to do, 2) what to eat, 3) how to speak, 4) how to think… and 5) who to vote for."

, are you?

<comment><USER3> There have been much more coherent articles written on that phenomenon.

Taleb's description is like a reverse horoscope: a bunch of vague generalities and irrelevant details that you're not supposed to identify with. You're supposed to say "oh phew, that's not me", and maybe shift a little bit toward Taleb's worldview to make sure you're not the caricature he described.

In the end, it doesn't convey anything. It's just a list of peeves and smarmy name-dropping.

This guy is a bestselling author, but if this article is what comes out of his head unfiltered, he clearly benefits from editing.

</comment></comment></comment><comment><USER5> 10 times more government as a percentage of GDP compared to a century ago. Wow. We certainly are having a lot of government in our lives and livelihood.</comment>


You Can Call the Super Bowl the "Super Bowl" - <AUTHOR> https://www.eff.org/deeplinks/2018/02/you-can-call-super-bowl-super-bowl <comment><USER2> As long as you're willing to waste your time and resources defending a lawsuit. Even if the lawsuit is winnable it's unlikely to be worth the trouble.</comment>


Airbus A320 – From Cold and Dark to Ready for Taxiing [video] - <AUTHOR> https://www.youtube.com/watch?v=uqKeSO6msDk <comment><USER2> As an A320 family pilot, I still haven't done cold and dark start. Maybe once day I will find an opportunity to.

<comment><USER3> Is this kind of thing normally done by ground crew / mechanics, then?</comment></comment>


Ask HN: Is doing research harmful in an idea harmful for a startup? - <AUTHOR>

I am finishing college, and I've been bouncing around ideas for a startup. In this case, I have some ideas pertaining to a solution for automatically generating websites - ideas which came on the heels of a course in automata theory.
It is possible that the way I want to go about doing this might possibly be of value to researchers in this field. Since I'm at a university and I have the opportunity to share ideas with professors, my question is this: should I even bring it up? I think it would be good for me to be able to flesh out this idea by working on it as a research project (if professors think it is worthwhile), and by the end I might possibly be able to publish. Hey, I'm at a university - the research opportunity and resources are there, why squander them?
But when I start the business, I don't want to have to worry about intellectual property. There are plenty of examples of things which have started out in academia, and then the researchers went commercial, and unexpected intellectual property royalty hacks cropped up.
So what I don't know is: should I even bring this up with a professor? Once I explain my idea during office hours, will that advisor want indefinite credit or profit? Actually, if an adviser helps, they would probably deserve long-term credit, but I would want to go about it in the right way.
Or should I just work on this independently, and don't even worry about trying to churn out another paper?
By "should I..." I'm asking "In your experience, do you have any thoughts or insights into this decision process?"
Thoughts? <comment><USER2> I am not a lawyer, so by no means consider this a legal advice, but I seem tempted to remember that the whole PageRank script that made Google be Google was actually their thesis at College, wasn't it? My memory fails now, but I am pretty sure they got it published somewhere before creating Google since their first plans were to sell the idea to some big company, and only after being turned down by everyone was that they decided to do it themselves.

</comment><comment><USER3> Your university has a policy on this. Different universities, different policies, so look into it.

</comment><comment><USER4> My initial thought is that sometimes ideas cannot be developed without the shelter of an environment like a university and one person shows typically don't accomplish much. So I think some ideas that later went commercial and then found themselves with this conflict might not have ever gotten developed at all if the originators had tried to keep it all to themselves. So one question you might ask yourself is: If I try to go it alone and keep it secret, will I get _anything_ done? If you think you can, that might be the way to go. If you get the feeling that would kill the project, then you need another solution -- whether this path or another path -- that involves working with other people.</comment>


3 Things I Hate About Elections - <AUTHOR> http://www.professorhollybell.com/2012/10/15/3-things-i-hate-about-elections/

<comment><USER2> What is this doing here?</comment>


Yale Students Demand Automatic 'Pass' Due to Covid-19 - <AUTHOR> https://yaledailynews.com/blog/2020/03/18/students-call-for-universal-pass/ <comment><USER2> Good luck passing Calculus II if you were given a passing grade in Calculus I without actually learning the material. There are plenty of other courses that will run into the same problem if their prereqs aren't actually mastered.

<comment><USER3> My little brother is currently attending RIT and what they did is allow anyone to take any course Pass-Fail. It's not an automatic pass, but it does mean it won't screw over your GPA if events have impacted your ability to perform.

<comment><USER4> MIT made all classes this semester effectively pass/fail. Makes sense to me. It has been wrenching, with different impact depending on each student's situation.

<comment><USER5> Is that how freshman year is graded, regardless?

<comment><USER4> First semester only.

</comment></comment></comment></comment></comment><comment><USER6> In contrast and great irony, my local community college has announced that they will go online and expect full completion as usual - and the students have accepted it, because of course the academic culture at a white label school for tradesmen and transfer students would be more rigorous, serious and refined than the one at a national pride.

<comment><USER7> Of course! A community college is actually producing students that go on to perform the jobs they are being credentialed for. Having incompetent graduates would be a devastating blow to their reputation.

<comment><USER8> Yale bubble has just popped.

</comment></comment></comment><comment><USER9> >According to Eileen Huang '22, requiring undergraduates — many burdened by sickness, hectic home lives or living thousands of miles away from the University — to devote the same level of attention and focus to their classes as they would in the Elm City seems unfair.

I think there is merit to this concern.

I don't know if passing automaticly is the right choice but experiences durring these events can be quite wide ranging.

Just for me I find that some my neighbors complain they are bored. Me, my kids are at home, I have to manage their schooling, I have to work, my wife needs to work...and the youngest needs constant attention. I've never had less time / sleep.

Now students might not have kids but they too might have a great variety of challenges other students / professors don't have.

<comment><USER5> Some do.

Some would otherwise be homeless.

All walks of life attend college.

<comment><USER10> To me that's the most compelling argument: equity. Some students come from a background with very few resources and an unstable home environment, or no home to speak of. These students shouldn't be at an academic disadvantage because of a global pandemic.

<comment><USER5> I mean, I agree, they shouldn't, but the reality is, they are.

Now, what happens if this extends for multiple semesters?

Are all the Ivy schools going to PASS/FAIL online until graduation?

<comment><USER10> I'm not trying to get into a lengthy discussion so I'll leave it after this comment.

> the reality is, they are.

But Yale admins/faculty have the power to change that. Whether the change is worth it (and what the best course of action is) is a matter for debate. But I wouldn't say that the best course of action is to sit back and say "that's just the reality of the situation" when we have a capability to effect change.

> Now, what happens if this extends for multiple semesters?

> Are all the Ivy schools going to PASS/FAIL online until graduation?

That's certainly not an ideal course of action, but (in my view) it may be what the Ivies are forced to do.

</comment></comment></comment></comment></comment><comment><USER11> This will prepare them well for reality. Working adults, I am sure, will have their demands for the continuation of their livelihoods fully met by their employers, their landlords, and their mortgage providers.

<comment><USER12> Except a lot of governments have indeed enacted policies that protect tenants and employees during this period.

<comment><USER13> Nothing is going to protect you from getting fired if you decide to just stop doing your job after they ask you to WFH.

</comment></comment></comment><comment><USER14> So how does this compare to Harvard, where students expect an automatic A even without Covid-19?

<comment><USER15> At least at HLS there's not such thing as an 'A'. You can get an F, LP, P, H, or DS.

DS is not equivalent to an A. DS is insanely hard to get. The professor can only give like 1 or 2 students in the entire class DS so you basically have to be top gun to consistently get DS.

<comment><USER14> Harvard College (the university's undergraduate arm) definitely gives As. Law schools are vocational programs. I'm not surprised it works differently there.

</comment></comment></comment><comment><USER10> Students at my college did this too. Just about half of the student body signed the petition. Ultimately the faculty board that makes decisions about grading modes refused to enact this.

</comment><comment><USER16> Hard to know what's right, under the circumstances. At the same time, it seems like their degrees should have an asterisk, to be fair to full graduates.

<comment><USER9> I'm not sure an asterisk really tells anyone about the critical thing....do they know this stuff? Can they do the job?

<comment><USER16> A degree attests to what one _has_ done, not what one _can_ do.

</comment></comment></comment><comment><USER17> How would this make sense? The degree and course grade indicates understanding the material and knowledge of your major. If you haven't been able to learn the material you shouldn't get a degree or grade that indicates otherwise.

If they believe that the quality of education has reduced they should demand a refund, or they can drop the courses they can't handle so that they don't impact their GPA, and retake them once it's easier again.

</comment><comment><USER18> ETH is continuing online and limiting the downside risk of the next set of exams. That seems like a better approach to me.

<comment><USER19> Quite similar in Waterloo. They also added a petition process for those who fail with special circumstances going on.

For those who don't know, both are top-level schools in Switzerland and Canada.

</comment></comment><comment><USER20> Before we jump to conclusions...

Undergraduates were forced off campus a few weeks ago.

Imagine yourself in the shoes of an international student who left New Haven in a hurry. You're now required to attend online lectures at 3:00AM local time. Five nights a week.

You don't have a reliable internet connection in your country. You lost your job when you left campus. You're missing out on office hours. You can't collaborate with classmates in the United States. You need to take care of at- risk relatives at home. You're in a state of heightened anxiety during a lock- down. Don't even think about taking a nap! Your next discussion seminar (with mandatory attendance) is in fifteen minutes... at 4:30AM!

Now, is it really so unreasonable to ask the administration to relieve some of this pressure? We should empower students to seek knowledge without sacrificing their health and family obligations.

<comment><USER13> Relieve pressure, sure. Free pass? What? I mean they still need to do the coursework. The school should refund their tuition and room/board, and allow them to complete the semester later.

<comment><USER20> Pass/fail grades are not factored into GPA calculations at Yale anyways. The idea behind a "universal pass" system is that it completely eliminates grades for the semester without leaving that section of the transcript empty. It's more akin to a participation trophy than an unmerited gold medal.

</comment></comment></comment><comment><USER21> I know some BYU students and they were given the option to see their letter grade and decide whether to take the letter grade or a pass/fail for each class. D or F converts to fail, anything else is a pass. Neither changes your GPA.

</comment><comment><USER22> I wouldn't want my doctor to be someone who got an auto pass on his/her exams.

<comment><USER23> Exactly. Standards cannot be lowered everywhere. If you don't have the knowledge to pass your examinations then take additional time to achieve proficiency.

</comment></comment><comment><USER5> or refund the tuition for the semester?

</comment><comment><USER24> File under: Universities are silly places.

</comment><comment><USER25> For context, MIT, Harvard and Stanford have all instituted mandatory pass-fail grading policies (in practice, this amounts virtually amounts to a guaranteed pass as well).

<comment><USER12> Columbia, UC Berkeley and Dartmouth too. I think this move is gaining traction.

</comment></comment><comment><USER26> A lot of Italian universities took a week to rearrange their complete offering with online courses, allowing full theory + practice + projects lesson in virtual mode - exams solutions are being studied and pass/fail is out of the discussion.

If low-funded Italian universities can do it, I wonder what's stopping the best universities like Yale with enormous quantity of money to do the same.

</comment><comment><USER8> Your Yale degree isn't going to mean anything in the 21st century. Everything that can be learned there can be learned on YouTube for free.

<comment><USER26> How can you be tested and kept accountable for what you are learning using YouTube?

How accurate is the information that non-expert can fetch?

<comment><USER8> Same way people do now without degrees? Screening in phases. Live interview or video interview. You can actually tell a decent amount about a candidate over the course of a few hours if you ask right questions.

</comment></comment></comment><comment><USER27> Perhaps they need to learn the life lesson that bad things happen. Sometimes it's really bad, really unfair. But you can always make the best of it.

It'll be harder for them than others but they can demonstrate an ability to overcome and achieve during hard times. That'll be a huge personal confidence booster for future hard times.

</comment><comment><USER28> 1\. It's _some_ students demand automatic pass.

2\. What students actually need IMHO is no tuition for this semester, and the opportunity for a do-over next semester (if the crisis is over by then). But that's more difficult to demand, so these people go for an easier, and lamer, alternative.

</comment><comment><USER29> I had a professor who once quipped "education is the only product for which the consumer demands less than what they paid." The diploma is worthless without the knowledge that goes with it.

</comment><comment><USER30> They paid for a service and did not receive it. Many have even been kicked out of housing. Sounds like one party broke the contract regarding tuition.

Pass or not it really makes no difference. College degrees are losing prestigiousness so who cares.

In five years post graduation it really means little. You don't go to college to learn you go there for the degree to get into that first door.

<comment><USER13> We truly live in such amazing times, where the principle of the transaction is more important than the achieved competency. This isn't Walmart, it's an education system. If they're not getting educated, the degree is completely meaningless.

<comment><USER23> Exceptions set dangerous precedents.</comment></comment></comment>


Z-Wave – Wireless communications protocol used primarily for home automation - <AUTHOR> https://en.wikipedia.org/wiki/Z-Wave <comment><AUTHOR> Looks like a number of devices operate under this protocol, and it was designed in 1999. I'm working to automate my home more and bumped into this trying to figure out how my door lock showed up on my security system without internet (I just bought a home).</comment>


Senior Unix Engineer saves Fannie Mae - <AUTHOR> http://www.tgdaily.com/html_tmp/content-view-41262-118.html

<comment><USER2> If the guy had been at all smart, he would have used someone else's laptop/login to plant the script, and he would have put it in the _middle_ of another _very long_ script.

Of course, maybe he did and this Makwana is taking the fall for someone else.

Of course, maybe Makwana really did it and plans to use the "I'm not that stupid... I would have used someone else's laptop/login and not put it at the end of a script" defense.

Man, Hollywood has screwed me up.

</comment><comment><USER3> It's going to take a lot more to really save Fannie Mae :)

</comment><comment><USER4> Huh, the first thought to my mind was "How many people have access to do that sort of damage"

How about tightening up their access control mechanisms next?

A _contractor_ had root access to all 4k boxes?

<comment><USER5> Contractors are bound by a contract too. There's nothing special about employees in regards to liability.</comment></comment>