SolarCity was insolvent when Tesla paid $2.6B to buy it, lawsuit says - <AUTHOR> https://arstechnica.com/tech-policy/2019/09/solarcity-was-insolvent-when-tesla-paid-2-6-billion-to-buy-it-lawsuit-says/ <comment><USER2> This is short term thinking. Tesla's ultimate goal is to provide the complete package of electric car, battery and solar generation for homes and businesses. Buying Solar City obviously ticked the missing box of solar.

That was the plan and good one. It probably hasn't gone as well so far as Musk expected at the time but the game isn't over yet. There is strong demand for the Tesla solar tiles when they finally ship in quantity and at that time this buyout will look much better.

<comment><USER3> The argument is that Tesla overpaid, not that they shouldn't have purchased.

If SolarCity was insolvent then Tesla should have paid less. This would be better for Tesla employees and shareholders.

<comment><USER2> So you're saying it's kind of like how HP overpaid for Autonomy? :) Valuations are tricky at the best of times never mind in tech. It's easy to have an opinion. It's a lot harder to prove it in court.

<comment><USER4> In this case it's a bit easier to prove in court because there is documented evidence of Solar City's auditor signaling the need to use "going concern" language, and top executives at Solar City discussing the dire financial straits that any further revenue declines would put the company in. Top executives who reported, ultimately, to Elon Musk, who also had access to all the same financials they were looking at. They're also unable to plead ignorance because Tesla's CFO at the time, Jason Wheeler, made a very frank presentation to the Tesla Board laying out all the reasons Solar City was a ticking financial timebomb, and this is also coming out in the lawsuit.

</comment></comment></comment></comment><comment><USER5> Does anyone else get the feeling these shareholders are shooting themselves in the foot by wasting Elon's time with this lawsuit? Or is it that this is fueled by a competitor? Sure it's not great if Elon used his power/influence to push the Solar city transaction, but Elon has created and will continue to create so much value for shareholders, surely it's in _everyone 's_ best interest to let him focus on building better products instead of distracting him with this noise?

<comment><USER6> He bought a falling company from himself and his cousins for almost 3 billion, plus the company had 3 billion in debt. The deal resulted in him getting half a billion more in tsla stock.

Tesla's market cap in June 2016 was 35 billion. It's 43 billion now. That's not that much value created. The S&P went up almost 50 percent in that time.

It's all besides the point anyway, since many shareholders sold their shares because of this fraud. They don't care what he's doing now, they just want their money back.

It's in _everyone 's_ best interest to have checks on self dealing CEOs. If people can't trust public companies to behave, the whole system breaks down.

<comment><USER7> Isn't that what the board is for?

<comment><USER4> The Tesla Directors are paid many multiples of the average at other comparable companies so that they will not question or push back against Elon Musk, and they include many personal friends and even his brother, who has no qualifications whatsoever to sit on the Board of a major automaker.</comment></comment></comment></comment>


Bring back the 40-hour work week - <AUTHOR> http://www.salon.com/2012/03/14/bring_back_the_40_hour_work_week/ <comment><USER2> I keep reading these sort of articles and wondering why the American people seem so opposed to basic employment law.

Here in Socialist Yurop, the Working Time Directive means that no employer can compel an employee to work for longer than 48 hours per week. All workers are entitled to a legal minimum of 5.6 weeks of paid holiday.

You all seem to agree that you work too long and don't get enough holiday. I've never once heard anyone say that they're happy with two weeks vacation and unpaid overtime. I'm not asking rhetorically, I genuinely want to know why the most basic sort of collective bargaining is absent from the political culture of the US.

<comment><USER3> _"All workers are entitled to a legal minimum of 5.6 weeks of paid holiday."_

Heh, at my current job I won't be eligible for paid holiday until _eighteen months_ after my date of initial employment, at which point I will receive five days of paid holiday for one year, and then ten days of paid holiday for the next four years. That's a pretty stark difference, I'd say.

Is Europe hiring software developers?

<comment><USER4> In Socialist Yurop as well, in most countries, there are different rules on when and how much paid holiday you get in your first year, meaning you cannot get hired and take a month paid holiday, it has to accrue. So you would get a week after a few months, for example, then more, and so on. It looks fair to me.

And yeah, in all tech hubs I know of, everybody's looking to hire, the market is, maybe not red-hot like Silicon Valley, but pretty hot anyway.

</comment></comment></comment><comment><USER5> _And it hurts the country, too. For every four Americans working a 50-hour week, every week, there's one American who should have a full-time job, but doesn't. Our rampant unemployment problem would vanish overnight if we simply worked the way we're supposed to by law._

The rest of the article says that 50-hour-a-week employees are no more productive than 40-hour-a-week employees, and don't get paid any more. Where do the extra jobs come from?

<comment><USER6> You are confusing productivity as a measure for the number of jobs.

We use man-hours as the measure for the number of jobs, so, if 4 people working 50 (hours a week) start working 40 that leaves 40 hours to be filled by another person (1 more job). Productivity actually increases even if the man-hours are the same.

</comment></comment><comment><USER7> ...but I'm quite happy with my 35-hour week, thankyou.

There's a lot that's wrong with the UK, but being forced to work for free thankfully isn't one of them.

I just can't imagine where people get the time for a 50-60 hour week. Once I've been to work, played with my son, fed, bathed, and put him to bed, and cooked, there isn't much time left in the day, surely?

<comment><USER8> Exactly. Where I live (Argentina) we have a 40 hour week that usually turns at least into 45 hours because most people work from 9 to 18 with an hour for lunch in the middle.

Working part-time after a long time of full time work my eyes opened to the possibility of the 36-hour week. I usually discuss with a lot of people how they feel about their work schedule and what they think about working 6 hours in 6 days instead of 9 in 5, and surprisingly most defend the 40-hour week because they prefer two days of rest. In my experience, they're overrated. The possibility of dedicating time to yourself, your projects, your family, throughout the week is priceless.

</comment></comment><comment><USER9> My standard work week is 37.5 hours, but Thursdays and Fridays I work half days, and from home, to spend extra time with my son, so it's currently 30 hours a week. I asked my team leader if she thought it was going ok, and her response was "it's not much more time away than a couple of unnecessary meetings".

It has also given me some time to work on projects on my free time that ultimately can be of benefit to the company, sort of unpayed 20% innovation time. But since I am grateful for the company being so flexible and understanding, I don't mind.

</comment><comment><USER10> _In the renowned 1993 study of young violinists, performance researcher Anders Ericsson found that the best ones all practiced the same way: in the morning, in three increments of no more than 90 minutes each, with a break between each one. Ericcson found the same pattern among other musicians, athletes, chess players and writers._

For Real Productivity, Less is Truly More: [http://blogs.hbr.org/schwartz/2010/05/for-real- productivity-...](http://blogs.hbr.org/schwartz/2010/05/for-real-productivity- less-is.html)

.

I don't expect 'managers' to understand this... Mythical Man Month is nearing on 40 years old, and apparently the current crop of tech leaders haven't bothered to read it.

<comment><USER11> This is true provided you have to master the instrument. Not when you compose music. They are two different things.

Typing is not the same as programing. I learned to type real fast long back. But I'm still learning the art of programming.

<comment><USER10> You obviously didn't bother to read the article or it's references.

</comment></comment></comment><comment><USER12> One of my thesis committee members told me after I finished that I did not like working for bosses unless they were very very smart. This article reminds me that working as a consultant beats working as an employee. It also reminds me why I generally detest bosses. The thought of being stuck with a brain that could think approvingly about "keeping butts in chairs" in those smug unlettered terms fills me with pity and horror.

</comment><comment><USER13> This is the original article: [http://www.alternet.org/visions/154518/why_we_have_to_go_bac...](http://www.alternet.org/visions/154518/why_we_have_to_go_back_to_a_40-hour_work_week_to_keep_our_sanity/)

</comment><comment><USER14> I agree with the general thesis of the article, but at least in the software industry there are two big problems with this reasoning.

The first is that, notoriously, if one programmer working 50% more time won't advance the project 50% faster, that is even more true if you try to increase by 50% the number of programmers. Software development is incredibly non- linear (and as a project manager I always have to struggle with my manager about this - it is incredible how much linear thinking is ingrained in so many people's minds).

The second problem is that, also notoriously, software developers vary incredibly in individual productivity, much more than hourly wages do.

So, where engineering (not just software) work prevails on other kinds of work, a few geeks working very long hours can really be more productive than more people working less hours. But this does NOT work in most other environments, and even in software development:

\- there is a lot of repetitive work to do that real geeks aren't going to do

\- there aren't enough geeks to do all the software development that our societies require

In the end, one size doesn't fit all, and solving this situation with regulation would be very difficult (even if some better regulation could help, especially if it could make unpaid overtime much more difficult/risky for employers). The best chance would be to have one or more very convincing examples, like Ford was almost a century ago. Any candidates?

<comment><USER15> You have a programmer who works for 13 hours a day. That programmer does three days in a row of 13 hours. That's 39 hours, not including any travel etc.

Give / force them some time off before they can start another block of 40 hour work.

"Flow" is mentioned so often, but I'd really like to see some good quality research to back it up. For sure people feel like they're in a zone, but how much of the code produced in that time is great quality, and how much is error-strewn garbage?

The need for standard weeks is still pretty strong, but that's not insurmountable problem. Really, when people talk of weeks they mean "continuous chunk of work with no 48 hour break".

A bigger problem is making people think that 60 hour weeks is normal, or honourable, and that a 40 hour week is lazy or disloyal or unproductive or harmful to the company. That's not true, and it's possibly leading to early death of some people. It's certainly making some people miserable.

<comment><USER11> _A bigger problem is making people think that 60 hour weeks is normal, or honourable, and that a 40 hour week is lazy or disloyal or unproductive or harmful to the company. That's not true, and it's possibly leading to early death of some people. It's certainly making some people miserable._

I like working a lot, making great stuff. Some people don't. But that's not my problem.

Asking me not to work, just because some body else doesn't want to, is injustice.

I have faced this situation in the past. I used to get a lot of work done in my last company(I was productive and used to push crazy hours) and by that definition I was learning, making and getting a lot of recognition.

Soon a bunch of girls went and complained to the manager its becoming a one sided game. And the suggestion they gave to solve their problem was to stop me from putting those extra works. Now here is my problems, for whatever reason if you can't/don't want to do something big in life. I doesn't mean everyone should do the same to make you feel good.

This is more or less like socialism. You force the rich to become poor just because the poor don't want to be rich.

EDIT: C'mon guys why would you downvote this? Choice to choose a worklife style is upto to the individual. Stopping Individual from achieving their goals is in direct contradiction to _freedom to pursuit of happiness_.

HN is becoming like reddit, things get up/downvoted on mood not on merit.

<comment><USER16> "Choice to choose a worklife style is upto to the individual. Stopping Individual from achieving their goals is in direct contradiction to freedom to pursuit of happiness."

Some might have goals similar to you. Others might aspire to work a 40-a-week job, be there for their spouse and children and not feel burnt out every day. Yes, there are people like you who might enjoy working crazy hours and being super productive. However, the person who is truly most productive in a 40-a-week job should also be able to achieve their goals without this cultural stigma around working a _normal_ amount of time.

<comment><USER11> Please note the person who works 8 hours a day sincerely is getting what he is supposed to get.

Also the person who works for 8 hrs + x hrs is getting what he is supposed to get.

If you are saying despite working for ( 8 + x ) hrs he must not get anything extra or he and the guy who works for 8 hrs must both get the same, defeats the very laws of karma.

Besides, The 8 hrs guy has a problem only if gets into _comparisons_ with the ( 8 + x ) hours guy.

The expectation that one must get paid the same but do little work compared to somebody else generally makes a classic case when the individual blames others for merely being _lucky_ for the comparative success.

<comment><USER15> The 8hour worker is getting what they're supposed to get.

The 8 + x hours worker is getting less than they're supposed to. Often they're doing x hours for free.

There can be several problems with that. Sometimes the company gets a lot of value from the x hours, and sells lots of product for lots of money, but doesn't give any money to the worker.

Or sometimes the worker is doing poor quality work, but getting personal value from the x hours (perhaps seen by managers as being more productive) and the other workers have to fix the errors, but are not seen as productive.

> _The expectation that one must get paid the same but do little work compared > to somebody else_

Quite often overtime is unpaid, or is paid at low rates.

</comment></comment></comment></comment></comment></comment><comment><USER11> Fact is, I'm productive with a 8 hour a day schedule if and only if:

        1. What I need to do is clear and known.
        2. I've been doing the is same everytime or something of similar pattern.
        3. No meetings and distractions in between.

But the fact is, none of this is true in our area of work. To some extent even if something similar exists it wont work for many reasons.

For every person who wants to go back home, there is always a peer who is putting in extra hours innovating, building and learning. By the well known rate of success coming at an near exponential rate to people to work hard and are productive, the rate becomes exponential if they add crazy work hours to it.

Building stuff requires a goal. Then implementation, experimentation, test a feed back loop and then back to implementation. And then this cycle goes on in iteration.

This requires tuits(Uninterrupted large workable free chunks of time) to allow a degree of focus and flow seep into the person. And most of tuits are generally available only early in the morning or in the night. This by default means you already agree to work crazy hours.

So in summary, I can't do a 40 hour work week because

        1. I will loose out to my peers in the long term race.
        2. Meetings.
        3. My work requires genuine supply of atleast two big tuits a day to remain competitive and have a good growth both money and career wise.

<comment><USER15> > _there is always a peer who is putting in extra hours innovating, building > and learning_

For every peer putting in stupid hours innovating, building and learning there are > 1 peers putting in stupid hours fixing errors of other overworked colleagues or just grinding through the stuff they could have done in 40 hours if they didn't have an asshole boss / broken business culture.

<comment><USER11> I don't know why you consider working hard as a broken culture.

<comment><USER6> It is broken if that "working hard" is not productive.

</comment></comment></comment></comment><comment><USER17> I think overtime is often the consequence of managers that don't know when or how to say "no" to client's demands.

</comment><comment><USER18> I really like days where I put in those 5 to 6 perfect hours and then instead of the meetings and email I just go hone.

<comment><USER19> What are you honing?

<comment><USER20> Typing skills.

</comment></comment></comment><comment><USER21> I find I get about as much done "working" 60 hours as 30.

</comment><comment><USER22> Any contention on this topic should be solvable in the market. Companies and managers that believe in the 40 hour week fight it out with companies and managers who don't. (This decision is made by managers - though employees have to agree) Different people have different amounts to give at different stages in their life. Let the market decide which approach is more enlightened, and let people decide how much they want to work.

</comment><comment><USER23> I believe hours worked is only relevant to the type of work being done. Yet I think it is overall unrealistic to expect a forty hour week. Having been raised on a farm I know that forty hour weeks are a vacation to some, even now self employed people would scoff at forty hours. We have great examples of what happened to many of these prized union jobs that limited work to forty hours on top of rules that prevented people from doing "other people's work". Not many of them are good, hence they moved into government jobs where there it is much harder to bankrupt the employer for lack of production.

You work forty hours a week to be average. No one I know who is well off works only forty hours a week. Now they don't do the same tasks all those hours but they are doing something. The key is making sure the hours you put in are beneficial not just "doing work".

The rest of the world certainly isn't going to work just forty hours a week. They upcoming economies are going to put in whatever it takes to get where they want to be. Those of us who sit back and claim enlightenment by denouncing such hours are only going to end up being passed by.

<comment><USER24> These concerns are addressed in the article.

tl;dr Working hours longer than 40 leads to counter productivity in the short and long term. 40 hour workers are more productive in all situations except those where workers have an abnormal singular focus (apparently symptoms of aspergers).

</comment></comment><comment><USER25> Personally, I used to work 40 hours a week, and felt that was enough and I shouldn't have taken on more. Then again I do a lot of volunteer work as well besides that, but it's something I love, and something I can do from home whenever I want and have the time. And as I live with my parents, I don't have a family to look after or anything, so it feels like that comes in the place of looking after my house and family etc.

Now they cut hours at my job and I work only 30, and I'd like to work 40 again. I find I often don't really do anything with those 10 extra free hours and I get less money.

</comment><comment><USER26> If it bothers someone to work extra they should not be doing that work. Because it means you are doing something you do not love. I do not mean to say you have to slave for 80 hours week but let's be honest when you want to create something you have to dig down and put efforts more than others that could mean working smart and putting more effort than others.

This just does not apply to developers it is same at wall street. Those who want to be at the top of their game are not there for money only they take satisfaction in their achievements and achieving goals.

</comment><comment><USER27> The 'knowledge worker' section would be a lot more convincing if it provided citations.

<comment><USER28> A larger question would be whether integrative living (i.e. working from home, spending your coffee breaks with your kids) impacts the optimal level of work.

I would bet that knowledge workers burn out FASTER from being overworked than manual laborers. Knowledge work, particularly the inductive side, relies on downtime in order to stay productive.

<comment> steve-howard Overtime and burnout were covered in Peopleware back in 1987. Looks like we're doomed to relearn our lessons again and again...

<comment><USER28> But my experience is that I burn out a lot slower if I am working at home and taking my breaks with my family. So that is a different circumstance not covered in such work.

</comment></comment></comment></comment><comment><USER29> Sorry, when did they ever go away?

</comment><comment><USER30> In technology, I actually think it makes sense for metered work demands (i.e things a person is told to do by management or clients, as opposed to learning new technologies, going to conferences, contributing to open-source) to top out around 25 hours per week. Even that's pushing it. The other 15-30 should be more open, long-term focused, and self-directed (because this component of the workweek is more autonomous, people can sustainably total 50+ hours without ruining their health, _if_ these autonomy conditions at met).

The reason that management in most companies doesn't recognize this is that, although the average worker could achieve as much in his or her best 4 hours, managers are afraid that if they did officially relaxed "metered" demands, people would use their best hours on side projects or career-focused efforts and throw the scraps to their metered work (and, in many environments, they're right). The reason for the 8 to 11 hour metered workday is to maximize the likelihood that these 3-4 peak hours per day occur somewhere in that window.

</comment><comment><USER31> If the boss asks me to work 50 hours, I work 30. True story

<comment><USER32> But you still sit at work 50 hours, or you go home after 30 hours?

It's true that I'd rather go home after 30 hours instead after 50 hours, but it's also true that I would be bored to death just sitting at work and doing nothing those extra 20 hours.

<comment><USER14> [Irony]Isn't that what Hacker News is for??[/Irony]</comment></comment></comment>


Sel4: We're going open source - <AUTHOR> http://sel4.systems/ <comment><USER4> This is an awful lot of fanfare for the open sourcing of something that was funded with public money by the government of Australia, using open source tools and technologies. Why isn't it already open source?

In general, I would like to see more software developed with public research funding required to be open source as part of the grant stipulation, ideally from early on. Too often tax-payer money is used to develop software which then ends up being closed source and providing profit to some commercial entity, instead of benefiting, you know, the people who payed for it – the public.

<comment><USER5> _Why isn 't it already open source?_

Not sure if you are Australian or not, but - unlike the in the US - <USER2> Australia there is no assumption that publicly funded work will be in the public domain.

Generally the way it works here is that bodies like Nicta (and CSIRO) are expected to make a return on the investments that are made in them - ie, they are expected to make money somehow. The default way they do that is generally IP licensing.

Personally I think this is very short sighted, but it shouldn't surprise anyone.

<comment><USER6> Just a little bit more on this: NICTA was originally set up as a research group by the Australian Government with the explicit mandate of commercialising its research.

The OKL4 and seL4 microkernels developed by NICTA were commercialised through the company Open Kernel Labs, which was subsequently acquired by General Dynamics (who thus acquired the IP of both projects).

At NICTA, we are very happy to see seL4 finally being open sourced: we really do want to see our work be used as widely as possible, and open sourcing it is going to be the best way of this happening. (So, in response to the grandparent thread, that is why we are making a big fanfare: _we_ are excited, even if nobody else is.)

<comment><USER7> Will there be future work with Genode, e.g. is the codebase going to stay focused on ARM or will it also support x86?

[http://genode.org/documentation/articles/genode-on- okl4](http://genode.org/documentation/articles/genode-on-okl4)

<comment><USER6> The seL4 kernel currently supports the ARMv6, ARMv7 and x86 architectures, though the proof only applies to ARMv6.

I am not sure what Genode's plans are. seL4 is a different kernel to OKL4, with a substantially different API, so it will be quite some work to move it across from OKL4 to seL4.

</comment></comment></comment></comment></comment><comment><USER8> Could someone with expertise in this area share what is really meant by "end- to-end proof of implementation correctness and security enforcement", and the practical implications of it? The words suggest that the kernel is 'proven' to be absolutely secure, which obviously is false (and I don't think the authors are trying to make that claim). So what are the precise implications for confidentiality, availability, and integrity?

<comment><USER9> Source: I have worked at NICTA, with the seL4 team, on the seL4 project, I've seen the seL4 source code and am (was?) a primary author of the user manual.

What they mean by this is that they have specified certain properties at a high level in a logical reasoning language they call HOL. These properties are things like the kernel will never reference a null pointer, or, the kernel will always run the next runable thread, or no application can access the memory of another application, or, a capability invocation will always terminate.

They then wrote a runable version of the kernel in Haskell (a purely functional language) and they have a mechanically checked mathematical proof that the Haskell code implements these features/properties. They then wrote a (nearly entirely) C implementation of the kernel and, under a relatively small set of preconditions, proved that the the C code exactly (no more, no less) implements the Haskell code, which implements these correctness and security properties.

A nasty side effect of this effort is that the C code is very strange, since it is more or less translated Haskell code, and the kernel code must necessarily be VERY small, about 10,000 lines of code, which is practically nothing for an operating system kerenl (it is a micro-kernel in the truest sense of the word). Another side effect is that the API bears almost no resemblance with "previous" versions such as OKL4.

<comment> a-saleh Man, I have so many questions :)

Why not just use the haskell version?

What did you use to check the haskell version?

What did you use to check that C implements what haskell implements?

Edit: I have read [http://ertos.nicta.com.au/research/l4.verified/proof.pml](http://ertos.nicta.com.au/research/l4.verified/proof.pml), but I'd like to know more about tooling. Like, did you use agda, e.t.c?

<comment><USER9> I can't answer all of these questions authoritatively, as I have more of a systems focus than a formal methods focus, but I can hopefully point you in the right directions. The various published papers and final release will be the right places to find all the authoritative answers.

1) Why not use the Haskell version? The Haskell version was (is?) "executable", but it ran only against a hardware simulator, never against real hardware. Haskell has a complex runtime which is not (easily) suitable to run directly on Hardware (although one student I worked with did port a subset of the Haskell runtime to work on top of seL4). Using Haskell directly would be slow, and would require the researchers to prove the correctness of the Haskell runtime implementation as well which would be a huge amount of work.

2) What did you use to check the haskell version? I was not directly involved in this. I believe the Haskell used to write the kernel was a subset of the language, they call "literate haskell" which was used to both implement and specify the kernel. This was somehow minimally translated into a dialect of Isabelle called HOL.

3) What did you use to check that C implements what haskell implements? A similar process was used for checking that the C implementation was a refinement of the Haskell. Again, a restrictive subset of the C language a tool was written to translate the C code into HOL (I think). I remember the team lead arguing that the way the C implementation was checked, both the code itself and the translator could be checked for bugs.

AFAIK, The tooling was almost all custom except for relying on Haskell and the Isabel theorem prover. The group had a lot of experience for building and releasing the OKL4 kernel so a lot of the dirty work was already done as well as an excellent "Advanced Operating Systems Course" which whips and tortures undergraduates into systems engineers and ideally PhD students. :-)

<comment> a-saleh Interesting.

I have already seen the approach "Lets design this in haskell and write production code in C" for [http://cryptol.net/](http://cryptol.net/), but due to limited scope (mostly functions of several hundered bits input and output as customary in crypto-primitives), they were able to check that the implementation adheres to specification automatically. The aim was to allways know that the c code does what it is supposed to, so that programmer can focus on mitigating side-channel attacks :)

I wonder if something similar would be applicable to writing the micro- kernell.

</comment></comment></comment></comment></comment><comment><USER10>
All will be under standard open-source licensing terms.

Hmm. Lumping together the mind-bogglingly broad variety of Free/Libre/Open Source licensing options as something 'standard' does not instill confidence.

That said, perhaps they are using something standard, like straight-up Apache, GPL, or BSD.

</comment><comment><USER11> This will be pretty exciting for anyone learning operating systems. More source to read.

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

<comment><USER9> Beware, since the source is a translation of Haskell into C, this is not an entry level source tree and is not straightforward to read/understand despite it's small (LOC) size.

<comment><USER11> If so, it'll still be interesting to see what they've done with Haskell to make a secure operating system from the L4 model--I assume they are also releasing the Haskell source as well, otherwise there would be no point to it all.

</comment></comment></comment><comment><USER12> There seems to be a lot of utility here for folks developing hardware based public key infrastructure like BitCoin wallets.

</comment><comment><USER13> Beware of bugs in the above code; I have only proved it correct, not tried it.

[https://en.wikiquote.org/wiki/Donald_Knuth](https://en.wikiquote.org/wiki/Donald_Knuth)

Anyway, here, the Haskell code should be considered the real source code, right?

</comment><comment><USER14> Does "end-to-end proof of implementation correctness and security enforcement" mean there is zero change of a bug or security flaw?

<comment><USER15> No.

There may be a flaw in the security model that they correctly implemented.

There _are_ bugs in every ARMv6 ever made, and some of them may allow crashes ore security vulnerabilites.

</comment></comment><comment><USER16> "In short, the implementation is proved to be bug-free."

Has any smart person looked at their claims enough to vouch for them?

<comment><USER17> Some discussion by smart people at [http://www.eros-os.org/pipermail/cap- talk/2014-June/thread.h...](http://www.eros-os.org/pipermail/cap- talk/2014-June/thread.html#16120) ... probably have to wait til after it is open source end of next month to say.

<comment><USER18> You can download seL4 binaries and a copy of the specification (190 pages, no proof) here:

[http://ssrg.nicta.com.au/software/TS/seL4/](http://ssrg.nicta.com.au/software/TS/seL4/)

</comment></comment></comment><comment><USER19> Can anyone comment as to how feasible/practical it would be to extend these proofs to a multicore chip?

<comment><USER20> Very, very hard, if you mean kernel threads running in parallel. However, if the other cores run separate kernel instances (machine partitioning, separate memory and everything) that would be more achieveable. UNSW call this the clustered micokernel approach.

<comment><USER19> Thanks for that. Kind of what I expected. I wonder if the problem could be simplified if techniques from deterministic/stable multithreading could be incorporated somehow to simplify the formalization ([http://dl.acm.org/citation.cfm?id=2566590.2500875](http://dl.acm.org/citation.cfm?id=2566590.2500875))

</comment></comment></comment><comment><USER21> This might become a good competitor for OpenBSD and the hardened linux.

<comment><USER22> Well, there's a lot of bits missing - this is a _microkernel_!

But I've seen seL4 before, and this is a very solid (if slightly weird- looking) foundation to work from.

I hope they choose a good licence; MIT or GPLv3 or GPLv2 or something. (It's a microkernel, so my general impression is GPL wouldn't be intended to spread between kernel components.)

This could be a QNX-killer. Eventually, one day, maybe a worthy replacement for OpenBSD or hardened Linux, but it's got a long way to go. It's ideal for anyone developing embedded hardware, however, and L4 variants are already very widely-used there.

Are you developing an open-source trusted security coprocessor? (I know at least two teams are.) Then this is probably what you want to run on it... of course, we'll want to check it ourselves as a community first, too, just in case.

</comment></comment><comment><USER23> Anyone from RTOS community know how this relates to INTEGRITY-178B ?

<comment><USER6> INTEGRITY-178B and seL4 are not related in terms of their source code or origin, though they do both aim at the same target audience (security and/or safety-critical systems).

I don't have a good knowledge of INTEGRITY-178B, but as far as I can tell some differences are:

* INTEGRITY-178B is a static separation kernel. seL4 can be used as a static separation kernel, but also allows for dynamic systems, for instance with processes being created and torn-down dynamically at run-time;

* INTEGRITY-178B has a proof that a _model_ of the code satisfies particular security properties, while seL4 has a proof that the actual C implementation satisfies particular properties;

* INTEGREITY-178B is certified to EAL6+, while seL4 has not undergone any external certification process. (Without having a good knowledge of EAL6+, my suspicion would be that the code-level aspects of seL4 would meet or exceed EAL6+ certification, while the process-level aspects would need work on the seL4 side.)

If someone has worked with INTEGRITY-178B, please correct me if I have made any mistakes.

<comment><USER23> Thank you for responding that is a good description.

I remember someone from one of the government agencies gave a talk at in college many years ago about INTEGRITY-178B and about this separation kernel idea.

That was maybe 7-10 ago. The idea was pretty neat. And the claim was that the future will belong to more secure OSes based on this separation kernel (microkernel?). And how say every little component -- memory, filesystem, mouse, display are all in userspace. He talked about ok general purpose computer at that time were too slow to operate in that way (so Linux was better and winning because of performance). But just wait some 10 years or so and machines will be so fast that it won't matter.

So since then that story kind of stuck with me that kind of prompted the question.

</comment></comment></comment><comment><USER24> Hmm, given how compilers & hardware can introduce incorrectness and security vulnerabilities in otherwise valid code, it makes you wonder if anyone can really claim "end-to-end proof of correctness" unless they include the specific compiler & hardware in their proof.

<comment><USER25> Concerning the compiler, in the link it is written:

 _" There is a further proof that the binary code that executes on the hardware is a correct translation of the C code. This means that the compiler does not have to be trusted, and extends the functional correctness property to the binary."_

(I wonder how that works but it is related to your compiler concern)

Now even though the issue of hardware (say rogue hardware with rigged number generators and whatever backdoors) is probably a real concern, I still think that seL4 and its codebase where hundreds of bugs have been automatically found (and manually squashed) is a big step forward.

<comment><USER26> On that note: what even is a correct translation of C when it has so many undefined behaviors in it's spec.

<comment><USER27> What if the code doesn't rely on undefined behavior?

<comment><USER28> Absence of undefined behavior in the C implementation is of course one of the things covered by the seL4 proof.

</comment></comment></comment></comment></comment><comment><USER29> Love the default bootstrap theme <3

</comment><comment><USER30> "In short, the implementation is proved to be bug-free."

This reeks of bull shit.

"We still assume correctness of hand- written assembly code, boot code, management of caches, and the hardware"

Sorry, I don't think you can claim you have a mathematical proof of the correctness of your kernel when you assume this much.

And where is this proof? I can't seem to find it anywhere on their web site. The only thing I can find is the publication

"seL4: Formal Verification of an Operating-System Kernel" [http://ertos.nicta.com.au/research/l4.verified/pubs.pml](http://ertos.nicta.com.au/research/l4.verified/pubs.pml)

which looks like it just talks about the proof, rather than providing it. Am I just blind?

This looks interesting, but the confidence which they espouse is very suspicious.

<comment><USER5> I'm not sure you are aware, but formal verification[1] is a well known and respected field of research. It does work, but it is hard to build practical tools using it. Nevertheless, if something is formally proven correct then for it to be incorrect one of three things must happen:

1) The proof is incorrect (which of course means it is no longer proven)

2) The prover has a bug (most proofs are done automatically). This is possible, but many of the same formal methods are used on the prover, and it is often build on a human-proved proof at the bottom.

3) Mathematics (the whole field) is wrong. This seems unlikely.

In reality, the problem with formally verified software is generally that it must interact with non-verified software (and sometimes hardware - <USER3> hardware can be verified too).

The wikipedia page[1] I referenced is worth reading.

[1] [http://en.wikipedia.org/wiki/Formal_methods](http://en.wikipedia.org/wiki/Formal_methods)

<comment><USER31> 4) It meets the specification but the specification is incorrect/specifies sub-optimal behaviour.

<comment><USER5> If you can fix _that_ problem in the general case then you are about to be a very, very rich person.</comment></comment></comment></comment>


Google Makes Google News In Germany Opt-In Only To Avoid Paying Fees - <AUTHOR> http://techcrunch.com/2013/06/21/google-makes-google-news-in-germany-opt-in-only-to-avoid-paying-fees-under-new-copyright-law/

<comment><USER2> I will take out the popcorn and enjoy how this will go down. I think that we will hear a lot of angry screaming in German in a month when the traffic is decimated.

And I wonder why google has just not sent the publishers a letter "Hey, - there is the meta noindex, nofollow and we also honor robots.txt, just put them on the frakking sites."</comment>


Ask HN: Setting to ignore /node_modules with find and grep - <AUTHOR> Searching files in terminal and node_modules is making my life extremely uncomfortable.
Project directory looks like so:

   project/
   ├── index.html
   ├── node_modules
   ├── js/
   │   └── scripts.js
   └── style.css
 I find myself using `find . | xargs grep "text string"` to search the project directory.
I want to ignore everything in node_modules all of the time.
I'm familiar with --prune and ignoring, etc.. but I want something like an alias in my .profile that ALWAYS ignores the contents of node_modules.
I've looked around, but I just don't know if I'm asking the question correctly.
Anyone have any solutions? <comment><USER2> Tried `git grep`? It's a nearly full grep, and will ignore things that aren't tracked in the repo.</comment>


Ask HN: What programming language offers the best all-in-one experience? - <AUTHOR> What programming language offers the best all-in-one experience? <comment><USER2> It's a varying question and depends what you mean by an all-in-one experience. There's no one perfect language.

My answer would probably be Python, though.

<comment><USER3> I agree. Languages have different fits for different problem domains. If you're trying to use a language in a domain where it doesn't fit, it's going to be a bad experience, no matter how good the language is.

Don't write an operating system in R.

<comment><USER4> You can't tell me what not to do!!!</comment></comment></comment>


Why I Still Like C - <AUTHOR> http://mitchgolden.com/essays/psychotic/psychotic10.txt

<comment><USER2> This isn't crankyness. If you try to generalise the thoughts on asm/C then it boils down to this:

\- _Abstractions will always be leaky_

and

\- _be prepared for when an abstraction leaks_.

As for the ideology part:

 _think for yourself and try to see beyond the hype_

And I have to say I absolutely agree.

For example, I've written maybe a handful of lines of assembly, and maybe as many lines of inline assembly. However, understanding assembly language has saved me many times. Compiler bugs exist. Sometimes you don't have access to debug info and a debugger, just the instruction pointer and a register dump. Sometimes the compiler just _can't_ optimise well enough.

C is just one level of abstraction higher, so that's probably the level that's going to leak through when your high-level-language interpreter fails for some bizarre reason. (recent Ruby segfaults anyone?)

It's not turtles all the way down, but rather a menagerie of different abstractions, and it's useful to know your zoology, as it were.

</comment><comment><USER3> I've just finished my freshman Java class and was severely disillusioned at how far from 'programming' it felt. I picked up a copy of K&R and have been enjoying myself since. I actually feel bad for my fellow majors who think that Java/OOP is the only way that things can be done.

<comment><USER4> _I actually feel bad for my fellow majors who think that Java/OOP is the only way that things can be done._

I feel bad for people that think imperative-style programming is the only way things can be done.

C is not the anti-Java. It's Java minus modern features and with more rope to hang yourself with. (Then again, someone actually told me that spending an entire day with Valgrind hunting down a memory leak was fun.)

If you want power, non-Java-ness, and modern features, learn a language like Lisp, Haskell, OCaml, etc. And learn Perl for actually getting things done.

<comment><USER5> ... meanwhile the entire Internet is powered by software written in C, including the very same browser you typed this message in.

I've been hearing how obsolete C is ever since high school (1994) yet pieces of successful programs not written in C-family is an order of magnitude less common: everything form web-servers to browsers, OSes and office suites and imaging software - all C. Meanwhile I've never had to install JVM on any of my computers, somehow I never run across a single piece of useful software written in Java (with exception of evaluating Jython and toying with Eclipse&Netbeans at work).

Perhaps it's running on my phone. If so, that's probably why the damn thing feels so anemic compared to Objective-C powered iPhone.

I don't know how C programmers do it, but somehow they just get things done.

Moreover, C remains the only choice of writing the most portable code ever. There isn't a reasonably popular CPU on this planet that doesn't have a C compiler for it, while Java runs only on "java computers".

<comment><USER4> C is entrenched. Everyone uses it, and because everyone uses it, everyone continues to use it. That doesn't make it good, though, just popular. Read pg's "Beating the Averages" for a more eloquent explanation.

You seem to think that Java is C's competition. It's not. I think we can all agree that Java is one of the worst programming languages ever created. (The VM is nice though.) Nobody is telling you to use Java or C++. They are telling you to use a dynamic language (Perl/Python/Ruby) or a functional language (Haskell/OCaml/Lisp).

 _I don't know how C programmers do it, but somehow they just get things done._

Sure, but their programs usually leak memory (ever use Firefox?), and their libraries handle errors by terminating the whole program (see PulseAudio; any error condition immediately calls exit(1)).

 _There isn't a reasonably popular CPU on this planet that doesn't have a C compiler for it, while Java runs only on "java computers"._

I don't optimize my life for solving problems I don't have. Every machine I want my code to run on has Perl, Lisp, Haskell... whatever. If C was the highest-level language I could use, then obviously I'd use it. But it's not, so I don't.

Finally, gcj will compile Java down to machine code; ghc compiles Haskell to native code. So I don't ever see a situation where I will absolutely have to use C for some reason (other than interfacing with C libraries, of course).

<comment><USER6> " _Sure, but their programs usually leak memory (ever use Firefox?), and their libraries handle errors by terminating the whole program (see PulseAudio; any error condition immediately calls exit(1))._ "

That's a poorly written program. You can just as easily System.exit(1) in Java, or to do it a more Javaesque way, throw new Error("im too lazy to do this right").

<comment><USER4> But C doesn't have any mechanism other than exiting or returning a value that indicates "false". Both are non-optimal.

One (exit) makes the code simpler, but makes the consuming application extremely flaky; the other bloats the code with a weird API where functions modify their arguments:

       errorcode_t do_some_work(int arg1, int arg2, int *result)

and forces the client code to check every single error and decide right then and there what to do.

It's possible to write code that way, but why would you want to? This is a solved problem; why keep using a square wheel when round ones are available?

(Yes, there is longjmp. Still a lot of work to use that square wheel.)

In the end, don't think I care what programming language you use. It doesn't matter. But I do think that C should be dying off now; it is much less useful than it was 30 years ago.

<comment><USER7> > _But C doesn't have any mechanism other than exiting or returning a value > that indicates "false"._

Of course it does, in fact you just said it yourself - long jumps. Back in late 90s I worked with the firmware for the Point of Sale terminals, PIN pads, etc. It was written in C and its error handling was exception-based. Behind the scenes it was just a handful of long/setjmp wrappers, but it did nevertheless implement semantics of try/catch/etc.

Additionally, "exiting or returning false" are not the only two options, nor they even the most commonly used ones. At least in the projects that I was exposed to. Kernel code (e.g. Linux, BSD) routinely uses int as a return value and it still somehow manages to be both readable and functional without being "bloated" or using "weird API".

Yet another thing to consider is that optional exceptions (such as those in C++) come with a non-negligible performance hit, so it is considered an absolute no-no to use them in a "fast path" parts of the code.

> _But I do think that C should be dying off now_

But it just doesn't. Bummer :)

<comment><USER8> "Of course it does, in fact you just said it yourself - long jumps. Back in late 90s I worked with the firmware for the Point of Sale terminals, PIN pads, etc. It was written in C and its error handling was exception-based. Behind the scenes it was just a handful of long/setjmp wrappers, but it did nevertheless implement semantics of try/catch/etc."

David Hanson's book "C Interfaces and Implementations" explains how this is done and provides (very high quality) source code you can use/learn from.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> Most of the article is "why I think learning assembly is important". I don't know assembly, but I do know how computers work (and I even know you have to trigger an interrupt to make a system call). I think he should just get to the point and say "people should learn how the computer works", rather than suggesting that you learn a programming language that makes you aware of some aspects of how a computer works.

 _It's like a very sharp knife: you can cut yourself as well as whatever it is you're trying to slice. It's really easy to write broken or inflexible code in it._

This is true of all powerful tools. I've seen horribly unmaintainable Lisp and Haskell. I've also seen very clean and maintainable Perl. C is no different than any other programming language, although it does actively discourage good code. You can ignore the discouragement, but why not use a language that encourages maintainability, or at least automatically deallocates memory when you're done using it?

Anyway, I don't think this article shows why the author likes C, or why someone else should learn C. Sure, learn C if you want to learn C. But you can also learn about your computer by just learning about your computer.

<comment><USER9> Dial your time machine back a few decades, and you'll see assembly programmers telling those C upstarts that they should learn assembly for all the same reasons. A few more, and it's the logic circuit designers griping that you can't trust instruction cards because you can't see the program. A few more, and it's the vacuum tube enthusiasts complaining that digital switches are slower, less reliable, and too small to debug properly.

If you want a visceral relationship with your hardware, get a soldering iron and go to town. That's a respectable hobby, and confers mega geek-points. If you want to write software and be productive at it, learn a real language.

C is a powerful tool, and every programmer should know it. But it's woefully underpowered as a fulltime software development tool.

<comment><USER10> And you know what? All those curmudgeons were right (except for the bit about vacuum tubes: transistor logic was never slower or less reliable than tubes, ever). If you don't know how your tools are put together, there will be areas of software development _at_ _all_ _levels_ which will forever remain voodoo to you.

You can do an awful lot of useful work while relying on voodoo, but eventually the voodoo will catch up with you and you'll end up with an ugly mess where a better trained developer would produce an elegant hack. That's no less true for a web developer using rails than it is for an embedded systems driver developer.

Basically, I've never known a great hacker who doesn't understand CPU architectures and at least a little bit of digital logic design.

As for C specifically, let's just agree to disagree. I'll put of the sum total of "great hacks" written in C up against any amount of C++ or Java you can find. It's true that for some problems (web development being a good example) there are better tools (scripting languages, databases) for the domain. But that alone doesn't make C "woefully underpowered".

<comment><USER11> "It's true that for some problems (web development being a good example) there are better tools (scripting languages, databases)..."

most likely implemented in C.

<comment><USER9> It's implemented in machine language somewhere. Programmers should know what a register is. It's implemented in electrons, too. And, some of the best programmers I've known were EE majors.

Don't get me wrong, it's wise to know your craft. That's never a bad thing. But it's foolish to use a tool that is, frankly, not as powerful.

Saying a tool is "powerful" doesn't mean "you can do lots of stuff with it." You CAN saw down a tree with a screwdriver. But a chainsaw is a much more powerful tool for that job. Yes, a screwdriver can do lots of things that a chainsaw can't, which only proves that it's a more versatile tool. The _power_ of a tool depends on the context of the problem you're trying to solve.

I'm guessing that screwdrivers are used in the assembly of chainsaws. They still suck for cutting down trees. Same with C vs just about every other language. C is a fairly small step up from assembly. An important step, no doubt, but for most tasks that software developers face, especially on the web, it's not appropriate.

<comment><USER10> I'm going to go out on a limb and guess that you've never actually worked seriously in C. You probably had to maintain someone else's code at some point, got confused by the linker or debugger semantics, and decided you hated it. [disclosure: I peeked at your blog and resume, and it seems I'm broadly correct.] That's fine: work in C is grounded deeper than web development. You don't have the scaffolding around you to provide a fallback for changes. Sometimes you need to fix bugs from first principles, and that takes a lot more knowledge up front than web work does.

But that's not the same as saying that someone who _has_ that background is as unproductive in C as you are. Seriously: spend some time writing something serious in C, you might like it better. It will certainly seem more powerful than it does to you right now.

<comment><USER9> You're "broadly correct" in the sense that the Republican Party is "broadly libertarian."

I spent 5 years writing almost 100% C and C++ in college, with detours into Lisp, Java, VB, and Ada. (Actually, I'd grown up on Basic, so VB wasn't a detour, really.) After school, I worked at a VB shop, but built a few side- projects in C++. I've had to fix things that were broken, and I don't have a problem with the linker or debugger semantics. I've used templates, and both has-a and is-a object extension. I am certainly not an world-class expert in it, but it's not like I tried it once, got burned, and decided I hated it.

I'm a web developer because I like web development better. For a variety of reasons, not the least of them the challenge of building code that is so portable it will run on 12 different browser/os combinations, and the opportunity to work in many different languages, I find front-end development much more rewarding.

My aversion to C is based on a simple rule of thumb:

      (usefulness of a feature) / (tokens required to implement it)

Lines of code is a pretty good fill-in for "tokens", but I had to change the rule when someone pointed out that a 500 character regex in Perl is hardly an elegant or maintainable program :)

Another way to express this is that the elegance of a solution is the number of tokens that are not essential to the solution and do not aid in understanding the intent of the code. For example, compare Javascript's closures with Lisp's or Erlang's syntax. On the other side, compare any of those with the mess of class and object boilerplate in C++ or Java or PHP.

Conceptual cruft is even more pervasive. If encapsulation _requires_ class/object constructs, then there is no way to get past that.

Some programmers will be able to create more elegant solutions than others, of course. But without changing languages, you can't get past the cruft that is built into language. (Or, in the case of C, the cruft that was not removed from the language.)

Again, "power" does not mean "you can do anything with it." C can be used to tell a computer to do anything that computer can do. But I'd argue that that's a naive view of the power of a programming language. There are things that are trivial to express in other languages, and require several lines to do in C. Just something as simple as comparing that two strings hold the same value requires about half as much conceptual overhead in almost any other language.

Or is there a version C with lexical closures, first-order functions and strings, and a garbage collector that I'm not familiar with?

I'm not sure what you mean by _You don't have the scaffolding around you to provide a fallback for changes._

The claim that C programming takes more knowledge up front than web work does is frankly presumptuous and a bit misguided. I've seen the Javascript that C experts write. It's terrible. In fact, I'd argue that since quality web work requires an understanding of semantic HTML, CSS, Javascript, maybe some Flash and/or Canvas chops, and probably at least one kind of server-side language like PHP or Java, it requires much more knowledge up front than almost anything else out there.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> The #1 thing that I hate about C++ is all the f _cking side effects that people can bury in their constructors and every where else under the f_ cking sun. I want to start swinging a baseball bat at all the f _cking idiots that don't think in advance of using the latest f_ cking cool C++ whatsamcallit.

When you are maintaining a very very large project, the best thing about C is that when you read the code it is fairly obvious what is going on, and you don't have worry about some innocent looking code causing a bunch of other crap the be executed behind your back.

On the downside of C, name space collisions are a problem and the ability to hide data and functions.

I vote they should add C++ style classes to fix the name space problem, and private and public keywords to hide data and functions. I don't want all of the object-oriented B.S. like constructors and destructors that makes it difficult to read and debug other peoples code.

Don't get me wrong.....I think some features of C++ are very useful, especially operator overloading which has allow us to make it easier to code big programs that handle lots of longer intergers and weird integer sizes like 56 bits, or 112 bits, or 128 bits. Yeah, these days we have uint64_t in C99 compilers, but back in the mid-90's we had to write code in C++ just because it had operator overloaded classes, which we also had to write.

Even though I haven't stated earlier...I do real-time embedded software...so I'm not going to be writing an interrupt in Perl or Python anytime soon. C is not going away in the real-time / embedded software / driver world anytime soon. It is still very very common!

</comment><comment><USER13> article reminds me of my granddad complaining that us youngsters don't know how to kill and clean chickens because we can just go to the grocery store and buy them already ready to go.

<comment><USER14> Programming is not like murdering chickens.

<comment><USER15> Programming in C is maybe a _little_ bit like murdering chickens.

</comment></comment></comment><comment><USER16> Obviously you should be familiar with C. This entire conversation, however, is misguided by comparing it to Java or to fancy high-level languages. It's apples and oranges.

Of all of those, only C/C++ offers extremely high performance as its key feature. Being primarily a shorthand for assembly, C occupies a permanent place as the systems and performance language of choice and will remain there. If your application demands performance, use it. If not, then don't.

<comment><USER17> Sure, but first write the application in a higher level language and then, if required, you can re-write the bottleneck in C. Otherwise what you are doing amounts to premature optimisation.

<comment><USER14> _Otherwise what you are doing amounts to premature optimisation._

That's a good insight - what language you use is also a form of optimization.

</comment></comment></comment><comment><USER12> >> C is a powerful tool, and every programmer should know it. But it's woefully underpowered as a fulltime software devlepment tool.

Only a inexperienced fool says such a thing! The bottom line is that it all depends on your what you are trying to do. For embedded / real-time / drivers / O/S, both C and C++ are perfect, but for middleware and scripting and many other high level things they aren't the best language.

</comment><comment><USER18> Just as a useful benchmark for all of you higher level language fans--- try programming without your C libraries...

<comment><USER19> Completely agreed. I've been doing Euler problems in Ruby/Java, and my friend does them in C. The difference there is very noticeable, and quite interesting at the same time. Obviously our programs are only compared when we use the same algorithm.

<comment><USER20> What difference is noticeable? Speed? Code ugliness? Coding speed?

<comment><USER19> I can typically speed through them faster, but the speed of the code execution is so much faster in C. Especially in basic number crunching.

</comment></comment></comment></comment><comment><USER12> The #1 group that says C should be dieing off is f-ing book authors and sellers! Why? Because they can't write a bunch of new books on an older language. It is old...so we can't write book and make money on those older things. New stuff is cool...yeah new stuff is cool...buy our books...buy are books.

</comment><comment><USER11> What's the answer to the p, q, r question?

<comment><USER21> What p points to shouldn't be modified (but p can be changed to point to something else).

q mustn't be changed to point to something else (but what it points to can be changed -- except that in this particular example, q will point to a string constant, which shouldn't be modified).

Both of the above.

<comment><USER11> Thanks!

</comment></comment></comment><comment><USER22> What is the answer to the second question?

int i[10]; <\- allocates memory for 10 integers

&i <\- pointer to the first element in the array (i.e. i[0]).

correct or not?

<comment><USER23> Geez. No.

int i[10]; does allocate memory for 10 integers (on the stack)

So i has the type int•. A pointer to a value: an array. A pointer to a value is the same thing as a pointer to the first value in the array. That's why you can use ++i, increment the pointer, and it will point to the second value in the array (++i => •i == i[1])

So &i is, wait for it, a int••, that is, a pointer to an array. So if you have an array of arrays, then you need to dereference twice. E.g. argv. It's a char••, so an array of strings which is an array of arrays of characters.

<comment><USER24> If you declare

int i[10];

you can't do

++i

because modification of the value of i is not allowed.

<comment><USER23> Yeah, but that's not the point. It's about which address points to which place. An array always points to its 0th member in C by default - that was the point. Declare int• j = i; and you can do as much pointer shuffling as you want.</comment></comment></comment></comment>


Ask HN: Is it time for a Secure HTML subset? - <AUTHOR>

The stories about the Tor site exploits made me think; why are people who are running Tor and supposedly concerned with security leaving JavaScript and iframes enabled?
The state of security on the web is pathetic. The best/only real indicator we give users that a site is supposedly secure is an HTTPS indicator, possibly with a basically meaningless EV indicator. In reality those are no indication that the site itself is safe.
So what if browsers supported an HTML Secure Mode subset which disallowed any JavaScript, iframes and other potentially problematic behaviors (such as form submissions to different domains, etc.) This would work like JavaScript strict, where the page itself would indicate it is made to this specification and the browser should hold it to it and throw errors/not display otherwise.
This could be used for sites where security is more important than bells and whistles. Like banking websites, government websites like electronic voting, etc.
Granted this is not a perfect solution, and it doesn't guarantee that the server side is any better, but it at least might be a step in the right direction. If browsers supported it and we made sites to the specification, it could give indication to users that there's a large swath of potential exploits that are not possible.
Does this idea have any potential or am I just thinking about this too early in the day?
EDIT: I realize that graceful failing is a key tenant of the web, so maybe it would just fail like HTTPS does and indicate to the user "This site said it was secure but it isn't." If it passes Safe Mode validation then it gets some kind of special, really obvious to the user indicator.
The idea here is to make a mode where a) you can be sure everything on the page is coming from the site you thought you were talking to and thus b) that the server itself would have to be compromised for the page to be compromised.
This mode could also have additional effects like indicating when a link on the page would take you away from this site, etc. <comment><USER2> This does exist for iframes: [http://www.html5rocks.com/en/tutorials/security/sandboxed- if...](http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/)

The sandbox attribute can contain any of these values:

allow-forms allows form submission.

allow-popups allows (shock!) popups.

allow-pointer-lock allows (surprise!) pointer lock.

allow-same-origin allows the document to maintain its origin; pages loaded from [https://example.com/](https://example.com/) will retain access to that origin's data.

allow-scripts allows JavaScript execution, and also allows features to trigger automatically (as they'd be trivial to implement via JavaScript).

allow-top-navigation allows the document to break out of the frame by navigating the top-level window.

<comment><AUTHOR> Good point. But it's just one small piece of what would be needed. And of course there's no indicator to users saying "This page is made to be more secure and passes validation."</comment></comment>