Just a thought, maybe a "tunnel vision" mask toggle? So I can focus on the center of the screen without all the peripheral noise. It doesn't have to be a significant loss, but dark edges and corners with a nice fade to the visible circle in the center. Whatever that equates to..
Oh that's not a bad idea, and easy enough to implement! I'll definitely get to it later today - I think because I play it on my phone the contrast is less obtrusive, but on a big desktop screen it's a bit boggling to look at
Could you not tackle this problem by not allowing this mingling of 'next' and 'current' variables? You would only allow a next variable to be a computation of current variables. Not sure to what extent this would limit the application of the paradigm, though.
You can allow mingling as long as you don't produce an evaluation loop. The existence of evaluation loops can be detected by the compiler (Metron does this already).
Google: a lot, most of their services has one. However, I believe they use an OAuth (-ish) service rather than session IDs to manage authentication, so cookies aren't really an issue.
YouTube: no major subdomains as far as I know.
Facebook: aside from developer resources (which require you to log on with Facebook), none really.
Baidu: not familiar with it, so no idea.
Wikipedia: one for every language. Furthermore, the Wikipedia of each language seems to be completely separate, both in content and accounts.
Reddit: a lot. Aside from the obvious api.reddit.com, users may use <whatever>.reddit.com and the subreddit's CSS may use this info to change the looks of the subreddit.
Instagram: no idea, but I believe the main interface is simply on instagram.com.
Netflix: just netflix.com.
Twitch: as far as I know just the main domain, no subdomains.
Spotify: a few services, like open.spotify.com and play.spotify.com, but they all require you log on separately.
It's pretty mixed, with some websites having a lot of subdomains, but not all of them requiring or using shared cookies.
Regarding romance: If you want a wife, make many male friends. Consistently be honourable, selfless, and good. Volunteer for your friends. Go out of your way. The networking effect is subtle, but your name will "spread through the marketplace".
Don't hunt for your spouse as a lone-wolf ...there's nothing that way but isolation.
I agree about marriage, but if you want the experience of dating around, for shorter, medium term relationships, you really have little choice but to hunt as a 'lone wolf.' (You don't want to end up on dates with girls who have 'husband' on the back of their minds, which is often what the settled down social circle delivers... and anyways it can be more rewarding to 'win' someone on your own instead of having them 'delivered' to you.). So seems a little dramatic to say there's only isolation since less committed romantic involvements can be fulfilling too, and some would even argue (thinking "Sex at Dawn" author/ TED talk) that it's what your biology craves.
Thanks a lot. To be honest, I've already went through the "change" described in the article, but the article helped me see the better picture. I now have a reasonable social life and a happy relationship with my girlfriend. Thanks a bunch for your comment and advice, have a nice day!
Reminds me a bit of Scratch[1], a tool that came pretty popular when the Raspbery Pi came out. Very simple programming interfaces that work with simple graphics, but can do a lot of things.
What you're missing here, is that bash wasn't the software with an error. It's like you use ice cubes for building a house, observing your house is melting and then blaming the developers of ice cubes for making such horible building blocks. Ice cubes were never meant to be used to build houses with.
> What you're missing here, is that bash wasn't the software with an error.
Is the FSF wrong for issuing a statement which says A major security vulnerability has been discovered in the free software shell GNU Bash. The most serious issues have already been fixed, and a complete fix is well underway?
I think you missed the news that there's a bug in bash.
And if you're making the argument that bash should've not been used in the first place because it's an ice cube or fragile or whatever, then you are with those who make the argument that bash is bad code.
Say that a car manufacturer builds a car for city driving and doesn't warrant or recommend it's use for off roading. However it just so happens that the car is tough enough that it makes a good offroader anyway and soon people start to buy the car for the express purpose of offroading even though the manufacturer does not recommend this use.
Some time later it becomes apparent that there is a weakness in the braking system that manifests itself after extensive offroad use but not with regular road use, and this becomes the cause of many accidents. The manufacturer then does a recall and refits the cars with an improved braking system more suitable for offroading even though they never intended (and still do not) for people to use it offroad they are just forced to accept this use case.
Great explenation. To add to your story: imagine being the car manufacturer, doing this all for free (as in beer) and still having people more or less wishing you dead for building a city car not suitable for offroad use. It simply doesn't add up and makes you feel pretty miserable, I guess.
Except that, in a world where Unix systems are almost exclusively used to handle network traffic, that off-road usecase should probably be considered the default. They've been selling city cars in a country that doesn't actually have any paved roads.
Except the FSF never said anything like "Please don't use bash for CGI, it's not secure enough". If they had, then they would have to recognize that bash is not secure enough for other uses as well.
How does it violate your freedom to warn you of a serious danger? The fact is they didn't know bash would execute code found in arbitrary application-defined variables. And that is why GNU calls it a bug.
Sure, it's a bug but it's not ultimately their fault that it had the impact that it did as a result of people using it for purposes they might not have had in mind.
I know about Shellshock and I know what it means. However, I think it's wrong to blame bash for the fact that almost everything seems to be vulnerable. Those developers were wrong by using untrusted user input in places where it didn't belong. It's the FSF's responsibility to release a fix simply because the whole world depends on their (the world's) own stupid mistakes when developing their programs.
> Those developers were wrong by using untrusted user input in places where it didn't belong.
Environment variables are text. So long as you control the name of them, and the name doesn't conflict with any other name in the system, there should be absolutely no issue with putting user input into environment variables.
Programs like bash should only be executing things that are explicitly marked as trusted code through a flag that is not contained in the value. Some distros have implemented a patch to this effect already in bash, disallowing bash from treating any environment variable whose name doesn't start with BASH_FUNC_ as anything but text. This resolves every single related vulnerability out there.
So you mean the fix is to add some magic constant that variables now have to start with?
I mean, come on, the issue is screaming at you! This is the same basic mistake of using a bunch of string concatenation to build queries for your database.
Bash is the shell I use to control my system with, it's made for convenience of the user. If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.
> So you mean the fix is to add some magic constant that variables now have to start with?
That executable variables have to start with. This is a perfect fix, because attackers can never choose the names of environment variables, because we know that that's a poor idea (anyone who does it is already vulnerable to people setting LD_PRELOAD and similar things). This is simply marking certain variables as executable, while everything else is not.
The default assumption, like it or not, is that if you set some random environment variable to some random text, nothing's going to happen. It's been like that since 1993, at the latest.
> If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.
Some things end up managing the system - DHCP, for example. It turns out that the shell is really, really good at managing *nix systems. Everyone can understand it, and everyone can figure out how to manage their system with it. The only real alternative would be perl, which nobody wants to code in, and has a greater learning barrier.
As for modern web frameworks - of course they shouldn't use CGI, although more because there's better/more performant alternatives than for security reasons. However, you find me a medium/large business which has absolutely no legacy code anywhere.
> This is the same basic mistake of using a bunch of string concatenation to build queries for your database.
Not at all. The string as a query is expected to execute. Environment variables in general are just data and not expected to be executed, even if some of them have special semantics and may indeed be executed.
Nobody knew BASH enumerated every environment variable and - depending on its content - maybe evaluated part of it for immediate execution.
It wasn't documented and it wasn't expected. It's not part of the expectations people have for a POSIX shell.
In your metaphor, it's more like the ice cube manufacturer has been making brick-shaped ice cubes and selling them through building suppliers, and they've been widely used as a building material for many years and the ice cube maker has never said anything about the slight risk of it melting at room temperature.
What you're arguing is that bash is not and was never a solid POSIX shell.
Liking the idea, too bad it's simply an awful experience with all the HN traffic. I hit "Sign up with Facebook", then "Edit what CodeFights can see", and the counter had already begun. After authenticating I got an empty pop-up which I closed by myself, and I finished the challenge. I then got the error "Authentication error".
However, I like the idea and understand that this experience is not what you've made so I'll give it a chance and upvoted it.
thanks for understanding woutervdb and for the upvote, would be awesome if you can give it a try now (the HN traffic has calmed down :) ) and let us know what you think -- email info @ codefights.com
Great site, awesome project, good stuff. However, I found some kind of a "bug": http://i.imgur.com/elpJSS8.png
At this point, you can't see what "kind" of F the first F is. They clearly are different, however I'm not a musician so I wouldn't know what it should be.
If relevant, I'm loading the website on a 27" IPS display under normal daylight conditions.