Ask HN: Surgery for RSI injuries? Running out of options... - <AUTHOR>

Over the last year or so, I've had increasing discomfort with my hands, arms and shoulders when typing. I'm getting worried as I now almost dread being at my workstation given it leads to physical discomfort, sometimes almost immediately after starting work. This doesn't bode well for professional development as a software developer.
I've tried a number of changes to my setup so far, but I'm still experiencing pain. Here's what I've so far:
- Avoid working on laptop as much as possible in favor of desktop setup with monitor, keyboard, etc.
- Purchased Kinesis Advantage keyboard (my third keyboard change this year)
- Switched to Evoluent vertical mouse. While this helped, I've also added an Apple Magic Pad as the mouse still results in hand/wrist discomfort
- Installed a keyboard tray on my desk to keep the keyboard near my lap as well as avoid resting my arms on my desktop surface
- Purchased carpal tunnel wrist braces. I try to wear these at night when sleeping. Still not sure if these are doing much for me though
At the moment my symptoms consist of:
- Very stiff, sore thumbs. The worst is my mouse hand. Just hitting space/enter on the Kinesis can become painful by the end of the day
- Tender/burning/numb finger tips on both hands. Mostly the middle, ring and pinky finger in each hand.
- Sore right shoulder (mouse hand). I've recently removed the arm wrests on my chair entirely to avoid lifting my arms at all
I feel like I'm running out of options.  I'm considering going to talk with a surgeon as I'm getting nervous since this doesn't seem sustainable in the long term and I'm worried I'll be unable to work in a few years.
I'd really appreciate any recommendations from others who hopefully were in a similar situation and found a solution.
Thanks <comment><USER2> <http://en.wikipedia.org/wiki/John_E._Sarno>

There is a lot to say on this but I don't have the time. Two things are important; to say that RSI is psychosomatic does not mean its not real or "just in your head". And I reject Dr. Sarno's "repressed rage" theory and think that RSI can just be a positive feedback loop between the perception and creation of pain. In your description of your symptoms notice how focussed you are on your body and your perception of pain, I think that is the trap.

In any event, his methods will work regardless of whether you accept his explanation of the cause. He's got a couple of books out that explain how it works so no expensive treatments. There are websites of people who have successfully recover from RSI and chronic back pain using his techniques.

<comment><USER3> tl;dr - this sounds nuts, but it worked for me

I did this... got one of his books (they're on kindle, ibooks and audible) and read it. i had rsi that increasingly got worse over a 3 year period until i couldn't drive, tried pretty much every non-surgical thing i could find (multiple doctors, creams, physio, ART, acupuncture, TENS, stretches, exercises, posture examined by ergonomist, different keyboards, switching mouse hands, trackpads, footpedals, foot mouse (wouldn't you know it, my knee started getting rsi), vitamins, supplements, break software with increasingly frequent breaks, switched to dvorak, wacom tablet for handwriting/mouse replacement), and things were still trending worse. it was hard to hold my new daughter for more than a couple minutes, and i was trying to figure out what work i could do that wouldn't involve a computer.

i can still remember running across sarno's book online on a random google search for rsi treatments, the way people remember where they were when they heard about the challenger explosion or 9/11. within a week of reading sarno's newest book (name escapes me now, but it is offputtingly new-age sounding), i had next to no pain, after a month, i'd say i was healed. it's now been 10 months, and i don't even think about my arms anymore, or follow any sort of treatment regimen. i'm literally back to normal. if someone had told me this was possible a year ago, i wouldn't have believed them, i thought i was going to be babying my arms and counting my keystrokes for the rest of my life. in fact, my physiotherapist told me in no uncertain terms that i'd be dealing with this for the rest of my life.

sarno's theory in a non-medical nutshell: there's nothing wrong with your arms, the pain is caused by limited blood flow to your arms/wrists/fingers. the lack of blood flow is caused by your unconscious. why is your unconscious doing this? to distract you from dealing with painful emotions. why your arms and not your back or something else? your subconscious isn't dumb, and knows what will seem plausible to you. how do you fix it? by understanding that it's happening (not, as you might expect me to say at this point, by dealing with your emotions/stresses through therapy). the last part is what most people seem to get hung up on, and most of sarno's book is trying to convince you that this isn't a crackpot theory.

here's the caveat, which is explicitly discussed in the books as well. sarno thinks most rsi (and other chronic pain) is caused by what he calls tms, but it's possible there is something physically/mechanically wrong with you, so you should see a doctor first to discount this. in my case, i'd already seen several and had conflicting diagnoses and recommended treatments that got me nowhere, so i dove right into the sarno treatment.

here's a couple links that you can read about it in more detail, but seriously, buy the book or get it from [http://aaroniba.net/articles/tmp/how- i-cured-my-rsi-pain.htm...](http://aaroniba.net/articles/tmp/how-i-cured-my- rsi-pain.html) [http://tmswiki.wetpaint.com/page/Repetitive+Strain+Injuries+...](http://tmswiki.wetpaint.com/page/Repetitive+Strain+Injuries+-+RSI) <http://podolsky.everybody.org/rsi/>

</comment></comment><comment><USER4> Have you spoken to a physical therapist?

There's quite a bit of space on the spectrum between "trying things on your own" and "surgery".</comment>


Ask HN: Anyone use GoGrid? Cloud Competitor Cheaper than Amazon? - <AUTHOR>

Got two questions:
1. What are your thoughts on GoGrid?
2. If you do use GoGrid, who do you use as your registrar for domain names or does gogrid act as a registrar as well? <comment><USER2> GoGrid is a great company to work with. Here's a link to another AWS posting. <http://apps.ycombinator.com/item?id=422225>

<comment><USER3> Offtopic: why is there an 'apps.ycombinator.com' mirroring 'news.ycombinator.com'?</comment></comment>


ControlMQ – Secure communications for control system applications - <AUTHOR> http://www.cognoscentisystems.com/ <comment><USER2> Wow. This is a 30 day trial offer over supposed "hardened controls". Pardon my skepticism, but proof or GTFO.

I already have access to ZeroMQ, RabbitMQ, Mosquitto, Californium, and plenty more. And they all are open source under reasonable licenses.

So can someone please tell me:

         1. Why should I trust your claim of security?
         2. Why your product is worth money when I can go Open Source for free?
         3. Why should I deal with Vendor lockin?
         4. Why should I trust you?

Well... The obvious answer is that it's not worth it, at any cost.

EDIT: I flagged it. I would encourage others to do the same. This is bad, horrible, no good junkware.

<comment><AUTHOR> Thanks for your thoughtful comments. Yes, I can understand your skepticism, and that is a good sign that you don't believe whatever folks are just saying. That is particularly good in the cybersecurity field as claims that are unsubstantiated are often made.

The problem with cybersecurity is that you can't prove a negative proposition. That is, it's not possible to prove that a system will never be hacked. That said, there are ways of increasing the cybersecurity of a system to the extent that a compentent attacker, i.e. a nation-state actor, will need to commit significant time, personnel, and resources to attempt to mount a serious attack. Most likely they will look elsewhere to attack rather than the network interface that our product protects.

We have achieved a high level of cybersecurity by using several principles (in addition to CIAA): 1) Integrate the cybersecurity capability with the middleware so it is "built in" into the same product. 2) Limit our scope to controls systems messages so as to leverage the highly constrained nature of these kinds of fixed format messages to have an extremely small attack surface. 3) Use logical construction of mechanisms to specify what should only happen, and then rigorously prevents anything but that from happening. 4) Root the security in H/W. 5) Protect the full S/W stack from H/W to the application 6) Enforce an autonomous posture for all components to prevent a "brittle" system architecture, which would lock components together.

As to your specific questions: 1) The only way to evaluate the cybersecurity of a system is through penetration testing. We've had several highly competent teams evaluate our technology and have failed to defeat it in any way. You should have your own penetration test teams test all of your systems before you put them into production, and then periodically continue to test them for vulnerabilities. That said, no system is perfectly secure. But, we've been accepting systems with poor cybersecuity for quite a while, it's time to raise the bar on what is acceptable cybersecurity. 2) You are free to choose open source or any product. The problem with current technologies is that they were designed before the kind of high-level cybersecurity we expect today was understood. These existing technologies are wed to their current protocols which can't be patched to make them more secure. Only a redesign from scratch will do that, which is tantamount to abandoning their current protocols. 3) Vendors provide a product with features that are useful. That's why we use them. Control of the technology is needed to ensure the proper implementation of the principles outlined above. 4) You shouldn't. See answer to question 1) above. We need to earn your trust. In a sense, cybersecurity is a conspiracy of trust. Without trust there is no security.

Some further details are provided on the website: www.cognoscentisystems.com

I would be happy to answer any other questions you may have.

David Viel

<comment><USER2> I flagged it because I saw this as a hand-wavey "magic code" combined with a website filled with market-ese. I've been long enough in this industry to smell this at a distance. But I see the [DEAD] was rescinded. Ill be willing to rescind my flag since a rep of the company is here (you).

_________________________________

> Yes, I can understand your skepticism, and that is a good sign that you > don't believe whatever folks are just saying. That is particularly good in > the cybersecurity field as claims that are unsubstantiated are often made.

It really has to do with multiple things here. First, is a new crypto implementation. That sets of major alarms with me, no matter who writes it. Especially so being infrastructure, this should be open source and publicly accessible for review.

Secondly, you're using a new IP protocol. Full stop. This should be absolutely IETF standard, reference design, full engineering review, kind of code. I see none of that. I would get not having gone this route if you're trying to get a new protocol spun up with a reference design. I'm thinking of IPFS, where everything's open and done in public on GitHub and IRC. In my opinion, they're going on the route of getting an IETF standard in a different way (of utmost transparency and collaboration).

_________________________________

> The problem with cybersecurity is that you can't prove a negative > proposition. That is, it's not possible to prove that a system will never be > hacked. That said, there are ways of increasing the cybersecurity of a > system to the extent that a compentent attacker, i.e. a nation-state actor, > will need to commit significant time, personnel, and resources to attempt to > mount a serious attack. Most likely they will look elsewhere to attack > rather than the network interface that our product protects.

You want to play this game? Sure, I'll bite. How do you know you don't have a protocol error baked in at the definition of how your stuff works? Sure, you all were smart enough to build it, and some pentesters you hired said it was OK. The basic idea with RFC's was that everyone, collectively across the world could collaborate on how a protocol would work, or not. Failure domains could be identified and caught before a full standard was made. Have there been errors in these base protocols? Sure have. But they collectively have been fixed.

How do you plan to have peer review of your __protocol __, let alone your implementation? Hope and prayer, I guess. And when it comes to infrastructure, that 's nowhere near good enough for me. I need an open, peer reviewed protocol with a clear reference example. You can build your middleware and I'd consider purchasing that for value-add. But "No Way" with regards to the actual protocol.

_________________________________

> As to your specific questions: 1) The only way to evaluate the cybersecurity > of a system is through penetration testing. We've had several highly > competent teams evaluate our technology and have failed to defeat it in any > way. You should have your own penetration test teams test all of your > systems before you put them into production, and then periodically continue > to test them for vulnerabilities. That said, no system is perfectly secure. > But, we've been accepting systems with poor cybersecuity for quite a while, > it's time to raise the bar on what is acceptable cybersecurity.

Absolutely NOT. The other way to prove cybersecurity of a system is to __prove __it. For example, I can write functions in Erlang that I can prove are mathematically correct. I can show any input and its related output. I can probe the state of the system and inspect it at any time. And I can functionally understand it from a formal aspect.

Your claim is "Oh just pentest it". That's what you have to do for a black box, but that only _delays_ major problems. For example, there's controllers on Hard Drives. Only the HD makers know about them, so nobody can do anything, right? Wrong. Enter Sprite_TM [http://hackaday.com/2013/08/02/sprite_tm- ohm2013-talk-hackin...](http://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk- hacking-hard-drive-controller-chips/)

This person figured out how to control all 3 ARM chips, with unknown instruction sets, from just probing, hacking binaries, and poking at stuff. Black boxes like what you're peddling __WILL __get hacked. And if they 're white hats, they will likely tell you. Or, exploits will end up on random Tor auction site.

The middle ground is a published protocol and reference code to bootstrap. It doesn't have to be feature-laden. But its the foundation of proper Networking code. And instead, hand-waviness is claiming "We hired some hackers, so we're good". That doesn't cut it, especially for critical infrastructure.

_________________________________

> 2) You are free to choose open source or any product. The problem with > current technologies is that they were designed before the kind of high- > level cybersecurity we expect today was understood. These existing > technologies are wed to their current protocols which can't be patched to > make them more secure. Only a redesign from scratch will do that, which is > tantamount to abandoning their current protocols.

[https://xkcd.com/927/](https://xkcd.com/927/)

Oh, also, MQTT specifies absolutely nothing about payload type. Technically, a publish to a MQTT broker can be a cryptographic payload, a DVD image, a boolean, or anything. The spec allows __anything __to be put in as a publish. From there, it would be trivial to extend MQTT to require a cryptographic signature. Mosquitto supports plugins that could verify data authenticity.

And there's also RabbitMQ (AMQP) with forward-and-store. Similar extensions to it are available as plugins. What I see here, is a strawman of "Something something security" and pushing an untested, unfounded, unknown protocol for IoT and industrial devices, and operating on the "Hope and Prayer" principle.

_________________________________

> In a sense, cybersecurity is a conspiracy of trust. Without trust there is > no security.

I disagree with this as well. I shouldn't have to "Trust". That's what "Proof" is about. Proof would allow me to accept the code, even if you are a bad actor (I don't believe you are, I only think your goals are misguided). If the foundations are solid, it wouldn't matter what you say, if anything.

<comment><AUTHOR> You bring up many valid points.

I won't say much about crypto at this point other than we plan on having FIPS-140-2 certified crypto in the near future.

Yes, we are using a new protocol, but I don't agree that it needs to be a full IETF standard. We are working within the standard IP 99 protocol. A protocol is just another piece of code, just like any other part of a systems code base. It just happens that this code talks to code on another machine. Should IETF or others review all code before using? Has all the code you use been so reviewed?

We don't know if there is a protocol error in the definition of our stuff. If we did, we would fix it. What we did is a careful analysis and design of a highly constrained solution that was then carefully implemented and tested. That's about as good as a human constructed machine can be built. If errors are found as the protocol is used, we will fix them, provided they are revealed to us. That's the problem with cybersecurity, you never really know.

You need a peer review of a protocol. OK, but I ask again, does all your code need such a review before you will use it? Or are you singling out network protocols? BTW we are considering making this an open standard for the language and the wireline protocol, but we need to see how this plays out first.

Respectfully, I stand behind my statement that a system can't be proven secure. I understand that there is a lot of good work going on in provably correct systems using formal methods. And I think that they will help greatly in making systems more correct, but they will never ultimately prove correctness in the mathematical sense. Take the Erlang code, how do you know it's design is correct? That is, maybe it does exactly the wrong thing. Or that the code testing the Erlang code is correct?

Black box testing is the place to start. Then progressively lighting the testing, from gray to white box is usually recommended. Yes, testing is not perfect, but has defendable arguments about its correctness. Hence, the movement to use test-driven development.

Yes, there is a chance that our product will get hacked. But, that is not the issue. The issue is: will that take more effort, time, money, and resources to do than for what is being used today? We think the answer is yes.

Whether a protocol, or any code, is published or not, it is still vulnerable to being hacked and that hack being kept confidential. The effect is the same.

MQTT is a good example. The payload can be anything, including malware, as in the example where a client gets compromised. Our protocol is highly restricted so that secretly passing malware in a message is highly unlikely.

Again, respectfully, I stand by the statement that security is based on trust. Proof has to be believed to be useful, so you have to trust the source of the proof, and who provides it.

Overall, we believe that our product is simpler and less error prone to configure, and less vulnerable to exploits then assembling all the technologies that have been mentioned here. We are providing just one piece of a cybersecurity framework that only covers controls network communications, as part of an overall cybersecurity plan.

<comment><USER2> My comment was too long, as deemed by HN. So I posted it here.

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

<comment><AUTHOR> Thanks for the detailed response.

I understand the need to see inside the technology to understand how and why it works. Some of our technology is being patented, so it will be published. Some is trade secrets, so we keep that closely held. These are business decisions that may change in the future as needed. We are considering publishing the protocol on the wire standard and the SIDL language, as so many people will likely want an open standard for these. We don't believe in "security through obscurity" as that is just delaying the inevitable and fooling ones self. On the other hand, we do have some competitors that may like some of our closely held techniques, which we would rather not share.

The example of the motor controller is a good one, and one that this technology handles well. In the case of a command to set motor speed the interface message specifies the acceptable range of values and the implementation on each side enforces those limits. So, the motor won't spin beyond its capabilities. These are just the kind of use cases for which the protocol was designed. With regards to RFCs, they are recommendations not specifications per se. That is, a vendor is free to implement the RFC as it sees fit. An offensive cyber operator told me that if you want to hack a network just open the RFCs and search for the word "may" and start there. So, what you get can be very vendor specific.

Our chief concern as to attackers is the nation-state actors. We believe that they have the best techniques and are at the leading edge of cyberoffense capabilities. Unfortunately, there work is highly classified and we only get a glimpse or an innuendo occasionally as to what they do.

One of the features of the technology that really enhances the defensive strength is the use of the highly constrained interface specification. If an attacker on a compromised client tried to shoehorn some malware into a message it would almost certainly get dropped as the bit combination in the message arguments would most likely not pass the constraint validation tests. Thus, the attack surface for the interface is greatly reduced from that allowed by other protocols.

We don't trust SSL, SSH, and SCP, as we've been told not to. We only use these during configuration when we tell users to disconnect the system from the network.

I appreciate the thoughts. Makes me think hard about what we're doing and how to communicate it.

What about the "flagged"?

</comment></comment></comment></comment></comment></comment><comment><USER3> They have re-implemented entire network stack above IP layer. They start from raw IP (protocol 99), and then added "AES, SHA, RSA, and elliptic curve".

So you cannot use TCP/UDP/TLS/QUIC -- they are too insecure; instead let's have a bunch of code designed by unknown people, likely with not professional crypto experience, and not verified by anyone.

Riight....

<comment><AUTHOR> Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are not professional crypto people. But, crypto is just the starting point for cybersecurity that is a necessary but not sufficient condition for a secure system. What we did was start with crypto, and related technologies like cryptographic hashes, secrets, etc. and built a secure messaging system using the principles mentioned above. This has so far shown itself to be highly successful.

Hi, The reply buttons have apparently been disabled. I guess cybersecurity is too controversial for HN ;)

I will reply here instead.

@theamk

1) UDP leaks information, thereby violating the C in CIAA. TCP is subject to the SYN resource exhaustion attack, and is connection oriented which is brittle. Both are vulnerable to packet replay attacks, which is a particularly troubling problem for controls. 2) The pen testers that evaluated our technology we believe to be highly competent. We are open to having the pen testers (US only) of your choice test our technology.

@pritambaral

Yes, see the quotes on our website. And we do in house testing as well. We are happy to have pen testers (US only) try to defeat the system.

<comment><USER3> Reply to your message edits:

> 1) UDP leaks information, thereby violating the C in CIAA.

Which information? Properly encrypted UDP only shows destination IP and port number. Your protocol shows destination IP and protocol number (99) -- since very few people use it, protocol 99 is as distinct as UDP port.

Moreover, if you are concerned with UDP port leak, you can just use a random destination port on server, or masquerade as some other UDP protocol. There is no such option with current ControlMQ system

> TCP is subject to the SYN resource exhaustion attack, and is connection > oriented which is brittle.

You do know about SYN cookies, right? And you know that SYN flood is easily defeated now -- for example, out of 5 most significant DDOS attacks in 2016 ([https://www.tripwire.com/state-of-security/security-data- pro...](https://www.tripwire.com/state-of-security/security-data- protection/cyber-security/5-significant-ddos-attacks-2016/)) , none used SYN flood.

> Both are vulnerable to packet replay attacks, which is a particularly > troubling problem for controls.

Any control connection should use encryption. Every popular encryption method (including TLS and QUIC) protects against replay attacks.

> 2) The pen testers that evaluated our technology we believe to be highly > competent.

Well, all I have is front page quote, and I see the words "We were unable to [...] observe [...] the message traffic" and "TCP and all the UDP ports only list that they are open/unfiltered". This apparently means they could not even use wireshark to observe the IP message traffic -- they just ran "nmap" and found not ports. This is pretty sad for a pentester. I would expect to see mentions of DOS attacks and fuzz testing.

For example, what happens if I just start sending random packets to your daemon? How many packets per second it can handle before it fails over? What if I compromise a client, extract a session establishment key from it (assuming you have one), and start to establish new sessions? how many will your server handle before failing?

<comment><AUTHOR> Good points.

The port number typically indicates a service that is publicly known and repeatable. This is leaked information, as each service will have a unique port number. The IP protocol of 99 is used for all communications so no differentiation of network traffic can be made using this information.

SYN cookies can be a solution, but it has limitations, and to overcome those limitations requires changes to the TCP protocol. It is also preferable not to use TCP for controls in order to avoid the coupling caused by connections. The network between components may also be unreliable thus causing the need for regular reconnections.

Replay attacks protection by TLS, etc uses sequence numbers which expects a continuous connection. There is the setup phase that must be taken into account and then the entire series of packets from that point on can be replayed. The goal is to run on unreliable networks so connections would constantly need to be reestablished.

We consider DOS attacks to be attacks on the network rather than the component.

The number of packets/sec that the daemon can handle is computer resource determined. But, >1000/sec is typical in our testing on commodity H/W. It has never failed due to load in thousands of hours of testing.

If a client (first peer) is compromised then it can send any message it wants to the second peer with which it is configured to communicate. But, only properly formed, valid range messages will be accepted. Let's say that the receiving component controls a motor that has a valid engineering range of 0 -1000 RPM. If a nefarious command came in to spin to 2000 RPM that would be rejected. The server (second peer) is not connection based so it will handle whatever packet arrive at the rate it can, and drop the rest on the floor.

So, overall we believe it is simpler and less error prone to use our protocol then set up all these complicated extra configurations.

<comment><USER3> I was going to type in the long, point-by-point response, but then I saw this:

> Replay attacks protection by TLS, etc uses sequence numbers which expects a > continuous connection. There is the setup phase that must be taken into > account and then the entire series of packets from that point on can be > replayed.

WHAT? You do know that you cannot just "take setup phase into account" in TLS unless you have both server and client secret keys, right? There is the whole "key exchange" step make it impossible?

If you write stuff like this, for god's sake, do not design encryption protocols. I am horrified about what your code does if you do not know/don't understand key exchange concept.

<comment><AUTHOR> Yes, but the packet replay protection is due to the sequence number of the packet that happens after the session is established.

BTW, our technology uses pre-shared keys.

<comment><USER3> > Yes, but the packet replay protection is due to the sequence number of the > packet that happens after the session is established.

The TLS does not use pre-shared keys. Instead, every time a client establishes a new connection, there is a "key exchange" phase. Here is a simplified explanation:

1\. client generates a random number, does some math on it, encrypts with server's certifcate, and sends to server;

2\. server generates another random number, does some math on it, and sends to client.

3\. after more math (see [https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) ), both client and server get the session key. If the exchange was not tampered with, both client and server get the same session key.

4\. client and server exchange messages encrypted with session key. If they both have the same session key, they will be able to decrypt the message properly; otherwise, the connection is closed.

5\. Now client can send a command, such as "open door"

The reason replay protection works is because every time session is established, the server will choose a different random number in step 2. So if you try to replay, then step 3 will generate different session keys, and step 4 will fail.

Once the connection is established, there is a separate counter for replay protection, but it does not have to be complicated -- because we know that the session key is unique to this session alone.

This is how TLS / DTLS / QUIC do replay protection. Do you agree that these protocols are fully replay-protected?

<comment><AUTHOR> Yes, I agree that TLS provides replay protection on a suitably reliable network. Don't know about DTLS or QUIC but I will look further into these. We didn't really look to much at TCP and TLS, etc. because early on we made design decisions to have components adopt an autonomous posture and work with unreliable networks, as can often be the case for controls. That led us to reject all connection based network protocols such as TCP to avoid the coupling it creates, and to create a very simple, one step protocol for robustness and simplicity. But, I can see where use of TCP and TLS could be useful, even for us, in some cases. To some extent this is a design philosophy that is biased towards simplicity. I've noticed that in the software industry there is a bias towards complexity. Almost a need among some to built "Rube Goldberg machines" for everything. Each time a new issue is raised the solution is to add new functionality or feature to handle it until the system is a complex monstrosity, instead of reevaluating the whole enterprise from first principles in light of new requirements. Our concentration is on design. As I like to say "Code is nice, but design is everything.", and its corollary "No amount of code ever made up for a poor design." Our concern was to remain compatible with standards to the extent needed to remain switchable and routable on Ethernet and IP networks, but to reduce the problem of controls messaging to the simplest possible level while retaining a high level of security.

<comment><USER3> Look, you keep saying "on a suitably reliable network". Where do you get this stuff? TLS replay protection is always present and does not depend on network reliability at all. You might not _establish_ TLS connection if your network is super bad, but it does not mean replay is possible.

Can you PLEASE tell me how unreliable network allows TLS replay (or DTLS replay, or QUIC replay -- they all do key negotiation)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> Nowhere on their page do I see a reference to anything doing actual control. No mention of integration with Allan-Bradley, or Siemens, or GE, or any other actual control system. If your not securing the link between the PC based portion of your control network and the part thats actually controlling things what's the point.

<comment><AUTHOR> Great comment. The kinds of industrial controls that you mention are the long- term goal for the technology. We are working on a gateway adapter for some of the most common industrial protocols, such as ModbusTCP, and hope to have a product out early next year.

The technology is built up in layers. The base technology we call SecureSieve. We used this to build the first product, ControlMQ, which is a message oriented middleware for use with controls type systems. There are many applications for a MOM middleware such as robotics, medical devices, automation, custom controls, defense, aerospace, etc. We are using the ControlMQ middleware to build the gateway adapters.

Some further details are provided on the website: www.cognoscentisystems.com

I would be happy to answer any other questions you may have.

David Viel

</comment></comment><comment><USER5> This website is horrible.

<comment><AUTHOR> Thanks. We built it ourselves. We're not web developers. We just wanted to get info out there. If we get major funding, we'll spend big on a fancy website.

</comment></comment><comment><USER6> How does stuff like this get to the front page?

</comment><comment><AUTHOR> Can my post get "unflagged" now?

</comment><comment><USER7> How is it different from zeromq?

<comment><AUTHOR> Great question. Some issues with ZeroMQ:

It uses TCP/IP which has security issues that can lead to resource exhaustion. The SYN is sent but the sender never acknowledges the reply, so the server simple keeps the resource reserved waiting for the sender to get back to it.

It leaks information in the message even if fully encrypted. Just the size of the message in a control system usually tells you what it is.

It doesn't protect against packet replay, which is particularly serious for control systems. An attacker can just sniff some messages, which are fully encrypted, authenticated, validated, etc., and save them for later. Then, when needed, resend them to reenact the former actions. E.g. "open valve" message is captured. Later, the "open valve" message is resent to, once again, open the valve, even though the legitimate user may have closed it and expect it to be closed.

<comment><USER3> Note: that answer is mostly incorrect.

1\. While simple TCP/IP implementations have SYN flood issues, there are plenty of ways to mitigate them, including SYN cookies and third-party firewalls and load balancers. In fact, the SYN flood mitigations are so good, that most modern attacks are either raw traffic, or higher-level connections.

2\. TLS pads your messages to block size (for example, 16 bytes). If your message size varies by a bigger amount, just pad all of your messages manually. This takes 2 lines in modern scripting languages. No need to switch to all-new suite.

3\. This is just outright wrong. If you have messages which are "fully encrypted, authenticated, validated", then it means you run ZeroMQ with either TLS or CurveZMQ. Both of them have full protection against replay attack.

<comment><AUTHOR> Great comments.

1\. See my reply to theamk above 2\. The padding is good, but it needs to be the exact same size for all packets, which implies always using the biggest size. 3\. See my reply to theamk above.

We are expecting to run over unreliable networks that may have intermittent dropouts, so connection based solutions would require repeatedly reestablishing the connections, which would be cumbersome. The replay attack protection only exists within a connected sequence.

Overall we think that our solution is simpler and less error prone to configure, and can operate over a wider range of conditions than existing solutions with fewer constraints.

<comment><USER3> 1\. Your reply was "SYN cookies can be a solution, but it has limitations, and to overcome those limitations requires changes to the TCP protocol." Can you tell me more about these limitations? I thought the SYN cookies work pretty well. And they are pretty simple to setup -- in fact, they need no setup at all, as they are already enabled by default in the recent distributions.

2\. Right, so how does your protocol solve a padding problem? Why won't this method work with ZeroMQ?

3\. As I was saying above, this is still wrong. Both TLS and CurveZMQ are protected against replay attack.

</comment></comment></comment></comment></comment><comment><USER8> Why is this in the front page ?</comment>


IPv6 now deployed across entire T-Mobile US network - <AUTHOR> http://www.extremetech.com/mobile/127213-ipv6-now-deployed-across-entire-t-mobile-us-network <comment><USER2> IPv4 only content providers beware:

T-Mobile's IPv6 service is an IPv6-only service that uses NAT64 and DNS64 in the network to connect IPv6 mobile users with IPv4 content. We believe that the majority of the bandwidth consumed by IPv6 subscribers will be native end- to-end IPv6 without any translation required by the end of 2012 as major content providers like Google, Yahoo, Facebook, Microsoft, and many others have demonstrated during World IPv6 Day

</comment><comment><USER3> They only mention the two Samsung Android models, but I'm pretty sure that the N900 will work with this as well. I'll have to give it a try, maybe this weekend.

<comment><USER4> That is correct, the N900 will work correctly. As will any Nokia Symbian S60 phone like the e73 and so on. They only listed the Samsungs since they are current. With Google now offering the Galaxy Nexus for $399, it is a pretty darn good deal.

</comment></comment><comment><USER5> Apparently the iPhone doesn't support it. Quite sad since they actually enabled IPv6 support in iOS4.

<comment><USER6> Yep -- lots of phones support IPv6 on the WiFi stack, but not cellular.

I don't think it's particularly hard to add IPv6 support tho -- probably just a software tweak in most cases.

<comment><USER7> From the T-Mobile FAQ at <https://sites.google.com/site/tmoipv6/lg-mytouch>

\-----

4\. My phone is not listed above, will it work with IPv6?

No, most phones do not have the Android radio firmware (RIL) that allows the phone to support IPv6 on the mobile interface. T-Mobile USA is encouraging all handset phone manufacturers to support IPv6. If more phones become available, we will update this site.

\-----

</comment></comment></comment><comment><USER8> link to announcement comment ([https://groups.google.com/forum/?fromgroups#!topic/tmoipv6be...](https://groups.google.com/forum/?fromgroups#!topic/tmoipv6beta/k_Sa2j1OuSg))

</comment><comment><USER9> Tested it on my Nexus S, works fine so far

</comment><comment><USER7> Excellent to see!</comment>


Ask HN: In need of good UX examples for web app - <AUTHOR>

Hi,<p>Trying to build out the user experience and interface for my SAAS and in need of inspiration. Do you guys know any good sites to check out? <comment><USER2> Try [http://www.uiparade.com/](http://www.uiparade.com/) and [http://ui- cloud.com/](http://ui-cloud.com/)

<comment><AUTHOR> Perfect! Thanks!</comment></comment>


Show HN: A Good Friend Made an iOS Game About Unicycling - <AUTHOR> http://theunicycleapp.com/

<comment><USER2> That unicycle doesn't fit the rider. His knees are quite bent even at the bottom of the stroke -- they should be nearly straight.</comment>


I was a 13-year-old growth hacker - <AUTHOR> http://justinjackson.ca/growth-hacker/

<comment><AUTHOR> In this post I reminisce about my BBS days: when I was 13 I was asked to co- SysOp a local bulletin board.

I recently found my journal, where I mentioned growing our user base from 35 to 236. It made me laugh, because I immediately thought: "You were 'growth hacking' when you were 13!"</comment>


From software developer to software business owner - <AUTHOR> http://petrospective.com/from-software-developer-to-software-business

<comment><USER2> Laughed my ass off at this one: "Programmers love writing code. Give us an interesting problem, some food and a dark room - and we'll be happy as pigs in mud."</comment>


Closer to truth: Scott Aaronson - <AUTHOR> http://closertotruth.com/contributor/scott-aaronson/profile <comment><USER2> For those unfamiliar with it, _Closer to Truth_ has a weekly TV interview program[0] that airs on public television in the USA.

[0] [https://www.closertotruth.com/about/tv- program](https://www.closertotruth.com/about/tv-program)</comment>


France bans smartphone use in schools - <AUTHOR> https://www.theverge.com/2018/8/1/17640476/france-bans-smartphone-cellphones-school-emmanuel-macron <comment><USER2> My thoughts as a High School teacher:

I have tried[1] to allow students to have their phones, teach them to use their phones responsibly, etc. It doesn't work. They are banned in my class.

I'm just a single teacher with basically no budget. I can't compete with giant corporations that spend millions on design, UX, UI, etc.

[1] Also, technically trying to teach kids to use their phones responsibly (or even generically teaching them how to be responsible adults) isn't legal state standard for any of my subjects so I could get yelled at by parents or admin for doing it and I would have no recourse. It's unlikely to happen out, but it is something admin can use if they don't like you and want to nail you on something.

<comment><USER3> In college if i was goofing off on my phone during lecture I would likely pay for it on an exam.

You could try silently writing down which days you saw a student on their phone & which days you taught the specific subject material.

Then when students get it wrong on a test that you grade you can add a comment along the lines of "this was covered on day X when you were on your phone"

You would also then have a nice report for parent student meetings, and the parents can do the enforcing

<comment><USER4> This is petty and time-consuming.

<comment><USER5> Being petty and being effective are often related as a teacher.

Cramming for tests has poor long term retention. So, even if it seems like a final should be enough to demonstrate competency it's generally a poor idea to upgrade a grade based on a final.

</comment></comment></comment></comment><comment><USER6> > "In reality, the ban has already been made. I don't know a single teacher in > this country that allows the use of phones in class."

Not allowing kids to use smartphones during class is a huge difference than not allowing them at all in school. Cell phones are huge part of people's lives, whether they like it or not.

<comment><USER7> > _Not allowing kids to use smartphones during class is a huge difference than > not allowing them at all in school_

Learning how to put down their phones while socializing and working will probably be more valuable to these students, in the long run, than scoring a few extra minutes of Instagram. It isn't like they can't use their phones once off campus.

<comment><USER8> > Learning how to put down their phones while socializing and working

How many years do kids spend in school? And how long do you think it takes to learn how to do that? Surely not more than one year.

Arguments of the form "They need to learn how to behave in later life, therefore they should spend 12 years behaving that way" are wrong. (The conclusion may be correct, but the reasoning is not.) Given that it takes only x years to learn that, the question is whether it's worth having them behave that way in the remaining 12-x years.

</comment></comment></comment><comment><USER9> My thought as a University student and only a year ago - high school student:

Phones are a really great learning aid. There are also people who prefer to listen and participate more actively in lessons instead of writing down everything written on the whiteboard, with a smartphone they can just take a picture of the whiteboard.

Smartphones are the smallest thesaurus and translator you can get.

Smartphones can graph or take the derivative of any function you want. Wolfram alpha is a wonderful application.

Smartphones can quickly give you the life background of any author. Which helps immensely when analysing literature.

I've never experienced any real problems at school in relation to phones, as the teacher could just tell you to put it away. They have all the power to give you an F if you don't abide.

Admittedly, I've been both at a good highschool and a good University, but banning phones seems like not taking the time to show students how to use those effectively, and at the same time tries to hide the issue of people just not being interested in their lessons. And a lack of phone won't help you grab their interest. They'll switch to talking with each other additionally disturbing those who do want to pay attention.

<comment><USER10> AS someone who was a teacher at A-level (age 16-18) in the UK for 17 years until last year.... I think you may be right in the best case scenario, but my experience is that the number of pupils who use smartphones (or the wider internet) as such is vanishingly small. Most people don't have the mental discipline to use it for the amazing academic tool it could be, and the bright, shiny things of social media etc fritter away their attention. I don't think the last argument ('they'll talk anyway') holds much water - it's possible for pupils to look as if they are working but are actually on a phone; other forms of interaction are much more easily detected (two or more kids talking, etc).

I was made redundant from both my (part time) teaching jobs around this time last year (through no fault of my own or performance, I hasten to add!) and I have ZERO intention of ever going back - my (anecdotal, of course) experience of the education landcape and students' interest and behaviour (which I feel is significantly due to the attention-leeching effects of their constant exposure to smartphones) led the last 3/4 years to be a horrible experience that I wouldn't repeat if they paid me double what I was previously earning. I sincerely hope I'm wrong, but I am greatly concerned about the effect that such technology (and unmonitored use most of the time) is going to have on those who have been exposed to it since a very early age (who will be coming through the education system in the next 10 years or so).

<comment><USER11> So the smart ones have to suffer for the students that dont want to learn; so lets just force them to not use tools to learn more efficiently. Hammer the nail that sticks out. We shall all be equally ignorant. Viva el socialismo!

<comment><USER12> Is it really because of political agenda though, or rather an issue of scale?

From a scale perspective you have basically 2 choices.

1) Treat kids like adults, let them do whatever so long as it doesn't impact others around them, and if they flunk, so be it.

2) Assume kids don't know best and impose rules you can enforce at scale, with the end goal hopefully being they learn the subject.

Either option gets you boatloads of complaints and anecdotes, depending on your perspective.

If you don't want efficient but merciless scaling (perhaps it's not working?), then we should explore another (new?) approach that lives within or expands upon (good luck!) the economic constraints. Ultimately we settle on something that seems "good enough", meeting as much of 1) and 2) without going bankrupt.

</comment></comment></comment></comment><comment><USER13> Oh how the times have changed! I graduated from high school over 18 years ago and ANY cell phone was confiscated and you had to go see the principal to get it back.

<comment><USER14> I remember many trips to the office to get my pager back

</comment></comment><comment><USER15> To be clear: phones have been banned in most French schools for years, but faculty had no legal authorization to actually touch the phone or look at it to ensure that it was off.

I haven't read the actual text of the law, but I believe that it gives faculty the authorization to do just that.

<comment><USER16> I guess this is different for private and religious schools. Our son's catholic school had no problem confiscating phones, 3DS's, or card games. To take them home them and the parent would need to pick it up from the headmaster's office.

<comment><USER15> Hum. Don't tell your kid, but I don't think that's legal :)

<comment><USER17> In a private school where the policy is clearly stated and the parents signed their agreement, this is a perfectly legal.

</comment></comment></comment></comment><comment><USER18> Surprised they weren't banned already. How can a teacher droning about valence levels possibly compete with instagram feeds, and much more so for younger kids.

Possibly even, aspects of smartphone use should be treated as a potential health risk, in the same ways as alcohol, tobacco, sugar, etc. (though not all of those are treated appropriately yet)

<comment><USER19> Re: sugar in schools: I am currently trying to break a sugar addiction and having more trouble than I had coming off several types of addictive drugs.

<comment><USER20> I've always wondered about this: How much is that a problem with letting go of sugar, and how much is it _finding_ things that don't have sugar in them?

<comment><USER14> When I quit drinking, (1L vodka/day for years cold turkey), I craved sugar like nothing else in the world. If removing sugar from your diet is anything like getting sober, I feel GP's pain.

<comment><USER19> This is interesting. I did some quick googling, heavy drinking interferes with insulin, maintenance of blood sugar levels.

> Frequent heavy drinkers can wipe out their energy storage in a few hours.

[https://www.medicalnewstoday.com/articles/312918.php](https://www.medicalnewstoday.com/articles/312918.php)

</comment></comment></comment></comment></comment><comment><USER21> I'm really not sure how I feel about highschoolers having phones.

On the one hand, not having one seems like it could cause isolation and practical/logistical problems.

On the other hand, the whole point of most of the smartphone ecosystem is to manipulate people and these people are especially prone to that.

Highschoolers therefore should be only allowed to use completely free (as in freedom) community maintained software/OS/hardware devices.

<comment><USER22> How about educating kids on the proper use of such powerful tools, including the concepts of FLOSS (and, in general, how to question and think critically)? TV is not the problem, having more kids watching Jersey Shore rather than some good documentaries is.

<comment><USER23> It's hard, these apps are built by a huge amount of people to maximize attention hogging and addiction. Fighting addiction without going cold turkey is nearly impossible. Awareness usually doesn't help. Further more, it is hard teaching people to think critically while their faces are stuck to their phone.

</comment></comment></comment><comment><USER24> Like much of education policy, this seems to help some at the expense of harming others.

For the intelligent & motivated, there will be unnecessary boredom during downtime/study hall, potential hatred for learning/school, and other negative effects.

For the lackluster students, this policy will help some pay attention to class, learn lessons, and complete work.

In general, however, I'd have to say I'm against it. Any widespread banning of freedoms or ignorance of new technologies will have outsized negative consequences.

<comment><USER25> > For the intelligent & motivated, there will be unnecessary boredom during > downtime/study hall, potential hatred for learning/school, and other > negative effects.

Boredom is a fact of life, and learning to accept it without forcing yourself to depend on a smartphone is an underrated skill.

> Any widespread banning of freedoms or ignorance of new technologies will > have outsized negative consequences.

This argument does not really apply completely to children. And it is not ignorance; they're free to use their phones as they please, after class is done.

I agree with many posters here: phones have been designed explicitly to rob you of your attention span. The amount of willpower and self understanding to deal with that healthily is far more than what most children can muster.

<comment><USER26> > Boredom is a fact of life, and learning to accept it without forcing > yourself to depend on a smartphone is an underrated skill.

There is a whole book on that topic:

www.amazon.com/gp/product/B06VTZYPTF

</comment></comment></comment><comment><USER27> I'm honestly very relieved I graduated from high school just before the iPhone was released (+ early FB days). JR HS + HS were anxiety-inducing enough...I can't imagine what it's like now.

</comment><comment><USER28> Good on France. Now all they need to do is mandate OCaml, the great French programming language and they will own the next 10 years.

This is where the UK blundered in the 80s, the government should have bought a million Archimedes for the entire public sector and jumpstarted the U.K. tech industry. We would be 30 years ahead of where we are today.

</comment><comment><USER29> I would like to see how this is implemented. As far as I know it's been proved impossible.

</comment><comment><USER30> This is how it was here in the US when I was a kid in the 90's with pagers and cellphones. I don't see what the big deal is. I'm surprised it's taken this long. I don't know how schools are today, but I would assume they would not have changed the rules and such things would still be banned in all of high school and below. If not, maybe parents should ask their schools why they changed the rules? Assuming of course that they don't want their kids to be on their cellphone 100% of the time in school, something that's inevitable if they are allowed to have them.

</comment><comment><USER31> If you can have "airplane mode" you can surely come up with some type of "school mode" (apps locked and calls in/out to certain specific numbers). Also nothing in the article re: smartwatches.

<comment><USER32> There is a "school mode": Off.

<comment><USER33> That may ask for parents unlock.

</comment></comment></comment><comment><USER34> Phones are a distraction to an institution that refuses to evolve. We don't work the same way, we don't entertain the same way but for some reasons we teach the same way as a 100 years ago...

<comment><USER35> Who is this "we"? Are you talking for all hundreds of thousands of schools of the world? All schools of France? Who are you speaking for?

<comment><USER34> I think you should read again my comment, the "we" doesn't refer to anything you mentioned.

"We" as people in developed countries who have the luxury of having kids in high school with smartphone.

Let me rephrase that.

People in developed countries don't work the same way as a 100 years ago. (farming, manufacturing, etc.)

People in developed countries don't entertain the same way s a 100 years ago. (social media, TV, etc.)

Almost everything is different. So, why are we trying to teach the same way as a 100 years ago?

</comment></comment></comment><comment><USER36> I will be supportive of this when adults decide to ban cellphones in cars when in the driver's seat. Studies show driver's even with handless systems are significantly more likely to get into car crashes.

If you support curtailing young people's cell phone use but don't support curtailing the use by adults which has proven to lead to traffic fatalities I'd have to ask you why.

<comment><USER37> First regular cell phone use is already banned in a lot of places, and everywhere has a general distracted driving law on the books. It's pretty tough to surf facebook or instagram hands-free.

Second, your essentially saying I'll support a ban that students don't like when drivers stop putting everyone a risk on our roads - why the linkage? You could support both today, or either independently. This sort of linear- justification derails a lot of necessary change with artificial preconditions.

</comment></comment><comment><USER38> Smartphones should've been banned from schools 5-6 years ago. It's too late now. These days kids start tapping smartphone/tablet screens at a really young age. Taking away there smart devices now is like sending them to school blindfolded. Doesn't matter if they use smartphones for work or as a distraction, they're hooked!

</comment><comment><USER39> I find it amusing and not surprising that a country like France would ban it at the national level.

</comment><comment><USER40> My daughter's (private) middle school in Washington State bans cellphones during school, which must remain in lockers. However, it is a paperless school, so they use laptops during class.

</comment><comment><USER41> My school had a very simple method in dealing with this. The phone got confiscated until the end of the semester. That was also in the late 90s. It was effective.

</comment><comment><USER42> Just use one after school. I see zero problems. Allow one to be used at lunch hour if you feel it's an infringement not to be able to post a selfie for 8h straight?

</comment><comment><USER43> This seems sensible, when I was at school we had dumb phones and even those were banned.. And all you could do on those was text message each other!

</comment><comment><USER44> > The measure prohibits the use of tablets, computers, and other internet- > connected devices as well.

Ban phones, sure, but no computers? Bring back the typewriter?

<comment><USER45> The ban only concerns "students under the age of 15", who typically take notes on paper. The teacher can also make an exception for pedagogical purpose.

> There are exceptions in place for students with disabilities and for the > educational use of devices in the classroom and in extra-curricular > activities

<comment><USER46> Sure but they also use Google and Wikipedia etc.

<comment><USER47> Under 15? Not really, can use purely offline sources for that generic material. Good skill as well. Still should have a basic computing class though, perhaps wrapped into a library class.

<comment><USER48> In my experience all printed material is incomplete, obsolete, or one-sided and frequently all three.

That is not to talk about materials that can't be encoded as text, such as instructions and how-tos for whatever the French version of shop-class is.

You would propose that students be taught such subjects as the French revolution, based on what materials are available in the school library? How can you even ethically do that, when the kids probably can't even get the complete text of the Tennis court oath?

<comment><USER35> I very much doubt the historical consensus about French revolution changed in last 1-4 years since last high school history books were updated and printed.

</comment></comment></comment></comment></comment></comment><comment><USER49> an article that I read about this claimed that turned off phones were allowed... It is still a step in the right direction though...

</comment><comment><USER50> tl;dr psa for everyone: configure your phone for grayscale, least animation, vibrate-only and turn off most notifications.

Smartphones are mental cocaine. Look around a city almost anywhere and most people are hunched over, staring at glowing glass and oblivious to almost everything... so much so the Dutch are putting crosswalk lights on the ground to keep people from walking into traffic while they're getting their fix. It's clearly unhealthy as focus, socialization and personal safety suffer.

<comment><USER2> Yes.

This is going to be very pop-pshychology, but I feel like smartphones are almost gambling-adjacent. Flashing lights and constant, small hits of dopamine.

<comment><USER46> Gotta ask, what kind of apps do you have on your phone? Flashing lights??

</comment></comment></comment><comment><USER51> Now if only we could do this in America...

<comment><USER52> Or maybe you should move to France.

</comment></comment><comment><USER53> Typical statist mindset.

<comment><USER54> Maybe so, but please don't post unsubstantive comments here.

</comment></comment><comment><USER46> There's more to life than homework, even when you're in school. If I have my work done and want to read Slashdot or Ars Technica, or if I'm between classes and want to check the news, that's really not something that should be banned at the national level.

<comment><USER32> You don't need to read the news every day, let alone every hour of the day.

It's an addiction to the way news is currently produced.

It's entirely reasonable to spend an evening a week reading up on tech news. It's not reasonable to have a compulsion to check the news whenever you have a down minute.

I'm guilty of that myself, I'm currently writing this while a program compiles but I wouldn't wish this on a developing mind.

Besides, there are other places where news and the internet is available, why shouldn't places legislate away having that 24/7 on smartphones during school.

<comment><USER55> > You don't need to read the news every day

As someone who votes, you should read the news on a very regular basis. Ideally that means reading a variety of news sources from a variety of political leanings.

<comment><USER56> > _As someone who votes, you should read the news on a very regular basis. > Ideally that means reading a variety of news sources from a variety of > political leanings._

Why? To poison your mind with lies and misrepresentations of reality? To get distracted from important issues and spend lots of time following irrelevant dramas?

Mainstream news has negative informational value these days.

<comment><USER55> Obviously you have the special truth from the only true source, and all news media is fake except for the ones who hawk gold pills and testosterone boosters - they know how it really is.

<comment><USER56> I don't have any special truth from a true source; I just believe that a typical news story is mostly misinformation intended to drive pageviews instead of presenting accurate picture of reality. I don't think adding more false information helps get a more true picture. I mean, you could try to tease out some true information by "averaging" news from multiple distinct sources, but that's pretty much a full-time job, and most news are just a waste of time.

(I mean, seriously. Doesn't everyone here know of Gell-Mann amnesia? Or are people just afraid to follow it to its logical conclusion?)

</comment></comment></comment></comment></comment></comment><comment><USER22> Typical prohibitionist mindset. Lots of people use X, we don't like X, we ban X instead of understanding how to properly and moderately integrate X into our lives. Smartphones and tablets are GREAT learning devices. If we keep blaming the ineptitude of teachers on devices the quality of education will never progress.

EDIT: part of the education process is to teach kids how to use and not abuse these devices and when it's appropriate to use them for entertainment. Telling them "you can play Fortnite for an hour after you finish this math challenge" is way better than "you can't play Fornite at school!". I remember having the same policy applied for when I was in school and we would play Pokemon TCG. When it was banned we would play in secrecy during class, when they gave up and allowed us to play during recess we stopped playing during class. It's just common sense.

<comment><USER13> You seem to be looking at this through the lens of best case scenario. These are kids, many if all of them are probably mid puberty. The phones are not being used to take notes. They are playing fortnight, doing whatever replaced texting at this point, and generally just ignoring the lesson.

<comment><USER55> Those kids and their newspapers! I bet all they are ever going to do is read the news and not focus on the lesson. Can't they read that muck-racking when they get home? It's going to rot their brains! Don't even get me started on that overtly sexual and disgusting ballroom dancing!

<comment><USER57> "Back in your day," were you allowed to just pull out a newspaper in the middle of class and read it? I find that doubtful.</comment></comment></comment></comment>


Comcast's 2Gbps Internet costs $300 per month with huge install fees - <AUTHOR> http://www.theverge.com/2015/7/13/8949207/comcast-gigabit-pro-price-300

<comment><USER2> Is this really 2Gbps or "2GBps if you are the only person on that drop" at 4am in the morning?</comment>


Show HN: Demo of Wiki and Forum coded in C under 80k - <AUTHOR> http://home.ronsor.gq:12321/cgi-bin/wiki <comment><USER2> I really think we should stop being so mean to the submitter. Sure the code might have problems and the whole approach might not be advisable, but I am sure they have learned a lot from doing this. Ronsor congratulations for actually shipping.

<comment><USER3> I think the negativity comes from the fact this site now linked on the front page of HN can be hacked to send malicious JavaScript to people...

Also, in my opinon, adding "Demo" means that it shows how to do it, but that's not clearly not how to do it _properly_.

<comment><USER2> Yes it should not be getting the attention it is getting right now, but we can approach this in a more generous fashion. Let's help rather than ridicule.

</comment></comment></comment><comment><AUTHOR> I'll upload the source code tomorrow...

Edit: Its also running on my 4mb flash openwrt router, and has NO dependencies

<comment><USER4> Excited to see the code. C isn't known for being great for writing high level applications like this, so I'm really curious what the source looks like. Especially since it has _no dependencies_!

<comment><USER5> you may be surprised how easy it is to write a http server that replies with html in C... its all just text going over sockets after all.

i did it myself a lot a long time ago by teaching myself, but you are right that using some full featured server and some high level language targetting web development has much more convenience, especially if you care about rich features and security.

<comment><USER6> They claim it's got no dependencies though - so somehow they've got their own sockets implementation crammed in there.

<comment><USER5> i doubt it tbh, i bet he means no /3rd party/ dependencies other than the ones that came with the development environment.

the C standard library and the usual set of headers and os functions that you get in most C environments is not what people tend to mean by dependencies....

<comment><USER7> POSIX?

Its quite possible to have a C-based sockets-/signals- handler in a single source file, say .. 48k lines of code or so. I've seen many robust system daemons with just such an implementation.

3rd party dependencies are definitely an issue that very few languages have managed to promote, since languages either want to promote (or demote) such circumstances as mass-package (i.e. mass usage of the language) in a broad commercial/industrial/social context.

But its not naive to write such things as a Wiki and a Blog in C. Just .. dangerous. I imagine there are, however, some good 3rd-party C libraries available to do less-dangerous implementations, however...

<comment><USER5> it never seems to actually be posix, but yeah that kind of stuff.

it is interesting stuff.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> It looks interesting. Unfortunately, judging from the comments here, it's also more or less useless. I really look forward to seeing the source code, though, but the _hard_ part is the part that seems not yet done - which is the security.

I mean, what even is the point of sending me a file with a txt extension if you're not sending text headers?

</comment><comment><USER9> What are your thoughts re: adding memory protection to C? (in other words: add a distinction between "pointer bytes" and "raw data bytes" and some rules regarding pointer assignment, arithmetic, and dereferencing that serve to treat the pointer bytes as protected memory of a "3rd space" that sits between kernel space and user space; thereby ensuring that a program can only obtain a pointer to either a stack location (with restrictions) or heap location that points to a byte in an allocated segment of memory?)

<comment><USER10> I've actually been building a teaching VM with these properties. You can't take the address of arbitrary values (so there's no distinction between lvalues and rvalues), there's no pointer arithmetic (instead you have type- safe primitives for record access and array indexing), all arrays (including strings) know their length and bounds-check accesses, and unions behave more like sum types, always knowing precisely what type they have stored. All these constraints ensure you can never convert a number to an address, or generate an address to an illegal value. More info about the goal and rationale: [http://akkartik.name/post/mu;](http://akkartik.name/post/mu;) [http://github.com/akkartik/mu](http://github.com/akkartik/mu).

I also recently found out about [http://eigenstate.org/myrddin](http://eigenstate.org/myrddin) which seems more mature with _very_ similar goals/aesthetics. I've been digging into it a fair bit.

Finally, on the extreme other end of the spectrum, there's Rust.

<comment><USER11> You should call this system "Java". <g>

</comment></comment></comment><comment><USER12> Now that more than enough people complained about security etc. I also want to add that a modern wiki doesn't really work with their own grammar anymore. Consider changing to markdown, restructuredText, MediaWiki, or Atlassian style (last not really suggested but better than nothing).

<comment><AUTHOR> I wanted to keep it small, so i didn't use markdown, MediaWiki, etc, since those are harder to parse

</comment></comment><comment><USER13> [http://home.ronsor.gq:12321/pub/ohshitwhoputthishere.txt](http://home.ronsor.gq:12321/pub/ohshitwhoputthishere.txt)

seems that cgi-bin is also writable, can't make the file executable though

[http://home.ronsor.gq:12321/cgi- bin/ohshit.txt](http://home.ronsor.gq:12321/cgi-bin/ohshit.txt)

</comment><comment><USER14> It is interesting from performance and low resource consumption point of view. Great work! I wonder if someone would like to do the same in assembly language for even more crazy experiment -)

<comment><USER10> Ask and ye shall receive: [https://new- hn.algolia.com/?query=Web%20server%20assembly&da...](https://new- hn.algolia.com/?query=Web%20server%20assembly&dateRange=all)

</comment></comment><comment><AUTHOR> During this testing period, I would like to thank everyone who found the bugs and other issues with it. I am now working on fixing them all.

</comment><comment><USER15> this is still an awesome project, unfortunately there will be lots of python and ruby hipsters here who will dismiss this project... it doesn't matter, since most software you use is built in C or C++, and that won't change anytime soon :-)

</comment><comment><USER13> Server stopped working after doing this:

/cgi-bin/wiki?../../../srv/www/cgi-bin/wiki\0txt.e

<comment><USER16> That was mean.

</comment></comment><comment><USER17> [http://home.ronsor.gq:12321/cgi- bin/irc.html](http://home.ronsor.gq:12321/cgi-bin/irc.html)

      <script type="text/javascript">alert('you guys better watch out for dat XSS and XSRF bidness');</script>

Oh god, this shit is sooooo not secure.

<comment><USER13> well you're missing a </xmp> to get it working

<comment><USER18> Whoops, somehow IRC is kill.

</comment></comment></comment><comment><USER15> back in the day people coded demos 4k in size with 3d graphics and music

</comment><comment><USER19> In for the source code

</comment><comment><USER20> Not trying to be snarky, but if the goal was to show why you shouldn't do something like this, you've succeeded.

Would you consider rewriting something like this in rust or go, and doing a comparison? I think you would have found things to combat XSS in either of those languages (safe templating), would be interested to see the differences... And if any of those languages deliver on their promise to be safer than C

<comment><AUTHOR> rust & go do not produce small enough executables for my use case. atleast i didn't do it using shell scripts.

<comment><USER20> Have you taken a look at dynamically linked rust/go? Also, go 1.6 is going to have dynamic linking also.

[http://stackoverflow.com/questions/29008127/why-are-rust- exe...](http://stackoverflow.com/questions/29008127/why-are-rust-executables- so-huge)

[https://golang.org/doc/go1.5#compiler](https://golang.org/doc/go1.5#compiler)</comment></comment></comment>