Cyclone Scheme – Cheney on the MTA with Native Threads - <AUTHOR> http://justinethier.github.io/cyclone/index <comment><USER2> This is a pretty cool project, but it doesn't have the library support of other schemes. Given CHICKEN's already Cheney based, I wonder if Felix could somehow integrate this work? Green-Threaded pre-emptive cooroutines are all well and good, but sometimes you want OS threads...

<comment><USER3> Cyclone author here. R7RS libraries and SRFI's will help to some extent, for example hashtable support was more or less plug and play. As Cyclone matures it could potentially support R7RS-large which is going to include quite a bit. But we'll have to see how much of that can handle "real" things like database, graphics, etc.

It would require major changes to the CHICKEN runtime to support native threads, but Cyclone does map out a potential solution.

<comment><USER2> >R7RS libraries and SRFI's will help to some extent, for example hashtable support was more or less plug and play. As Cyclone matures it could potentially support R7RS-large which is going to include quite a bit. But we'll have to see how much of that can handle "real" things like database, graphics, etc.

Good news!

>It would require major changes to the CHICKEN runtime to support native threads, but Cyclone does map out a potential solution

Oh well. Well, at least there is hope.

</comment></comment></comment><comment> david-given Metropolitan Transit Authority, apparently, and not Mail Transfer Agent as I had originally thought. Although knowing this hasn't made anything clearer.

About five minutes of my life died to bring you this information.

<comment><USER2> Cheney on the MTA is a strategy for efficiently implementing continuations, TCO, and garbage collection, and allows you to create a continuation with no immediate cost. It's a pun on the song "Charlie on the MTA" because of how it's implemented, like Charlie, it "never returns." For more info, see "CONS Should Not CONS Its Arguments Part II: Cheney On The MTA" By Henry Baker.

<comment> david-given Yes, that was where I eventually tracked down the meaning (in the footnotes where it was hard to find, although they were good enough to quote the verse).

The thing about pop culture is that firstly it dates _really badly_ , and second is that it doesn't work across cultures. I'd never heard of the song before now..

<comment><USER4> "Charlie on the MTA" isn't really "pop" culture, it's Boston (area) culture, originating over 60 years ago. Not surprising that it ended up in technical literature around Scheme.

<comment><USER2> Boston area? I live in New England, and while not exactly the most common thing, it's fairly well known.

I've seen more than a few people who thought the Boston T charged you on your way out their first time in Boston because of this song.

</comment></comment></comment></comment></comment><comment><USER5> I thought this might have had something to do with the Cyclone safety-oriented C dialect, but apparently the similar name is coincidental.

[https://en.wikipedia.org/wiki/Cyclone_(programming_language)](https://en.wikipedia.org/wiki/Cyclone_\(programming_language\))

</comment><comment><USER6> Can anyone point me in the direction some call with continuation and stack and heap explainer? It would be great if it was brief and visual but I'm willing to read up. I just want to make sure that an explanation of call/cc is forthcoming.

<comment><USER3> Here is a basic introduction to the stack and heap, with examples in C: [http://gribblelab.org/CBootcamp/7_Memory_Stack_vs_Heap.html](http://gribblelab.org/CBootcamp/7_Memory_Stack_vs_Heap.html)

This might help with continuations: [https://en.wikipedia.org/wiki/Continuation](https://en.wikipedia.org/wiki/Continuation)

Here is a really simple example of simulating a C return using call/cc:

      (display
        (call/cc
          (lambda (return)
            (display "hello ")
            (return "world")
            (display "never reached"))))

<comment><USER2> For continuations, I would actually recomend "LAMBDA: The Ultimate Imperative" ([http://repository.readscheme.org/ftp/papers/ai-lab- pubs/AIM-...](http://repository.readscheme.org/ftp/papers/ai-lab- pubs/AIM-353.pdf)). It's not exactly light reading, but it gives the best explanation of continuations that I've seen.

If you just want the simple explanation: A continuation is a copy of the return stack at the instant it was captured. When a continuation is invoked, that copy replaces the stack.

<comment><USER6> This is perfect! Thank you!</comment></comment></comment></comment>


BP oil rig modelling software showed cement unstable days before blast - <AUTHOR> http://www.computerworlduk.com/news/it-business/3248321/deepwater-horizon-modelling-software-showed-bp-cement-conditions-unstable/

<comment><USER2> I like the subtitle better: Oil giant decided data was unreliable and took other steps.

Just remember this when the reverse happens, where the model is wrong and they ignore all evidence to the contrary.

<comment><USER3> But did they decide the data was unreliable because they didn't like the conclusion, or because they had genuine reservations about the validity of the model and/or data? And if they did, why check the model, anyway?

What worries me about the mentality of "I'm not confident in this data, but let's check the model anyway" is that being irrational creatures, we're likely to use a positive result from the model as evidence that everything is okay, but ignore a negative result because the data is unreliable. That is, different results, same conclusion. This is not logically valid, but we're irrational creatures and it takes discipline to avoid the fallacy.

<comment><USER4> I assume they did not like the conclusion.

 _The company conducted a separate negative pressure test...

The test was failed, but was – for an unexplained reason – deemed a "complete success" by both BP and rig owner Transocean at the time, a presentation on Monday said._

</comment></comment></comment><comment><USER5> It's rate of false positive that really matters. When that software says something is wrong at magnitude-X and with a very low false positive rate that thing is really wrong at that scale, then I shall agree it was BPs fault for ignoring it.</comment>


Spiped – symmetric, encrypted, authenticated pipes between sockets - <AUTHOR> http://www.tarsnap.com/spiped.html <comment><USER2> Amazing project. And I love the understated tone of this in the README:

"Security Requirements: The user is responsible for ensuring that any individual connection does not transmit more than 2^64 bytes."

If you don't happen to know how big 2^64 bytes is, it's over 18 BILLION GIGABYTES! We can probably safely assume most of us will never hit that limit on a single connection, haha.

Ref: [https://code.google.com/p/spiped/source/browse/trunk/README](https://code.google.com/p/spiped/source/browse/trunk/README)

<comment><USER3> You also have to ensure that you don't create more than 2^64 connections using the same key.

<comment><USER4> Do you have any recommendations on how to manage this? I realize this number is quite huge, and likely will never become an issue for me, but I'm not sure how I would manage or monitor the amount of connections a third party application creates.

<comment><USER3> Don't try to count, just establish an upper bound. "I have 1000 servers using this shared key, and they each open at most 1000000 connections per second, so as long as I change the key in the next 500 years I should be fine."

</comment></comment></comment></comment><comment><USER5> I use spiped every day the same way I would ssh tunnels, except spiped is rock-solid, dealing with flaky network with no problems. I highly recommend it.

<comment><USER3> _except spiped is rock-solid, dealing with flaky network with no problems_

In case anyone is wondering about this: When you set up an SSH tunnel, you have a single persistent TCP connection which everything runs through. If there's a network glitch which kills that TCP connection, everything dies. With spiped on the other hand, a separate TCP connection is used for each "pipe", so a network glitch won't kill a connection which isn't actively sending data, nor will it prevent future connections from being established.

<comment><USER6> Everything you say is true; but in some cases, you _want_ to know that things have disconnected and data won't be coming through even if it should. ssh -L (with ClientAliveInterval / ServerAliveInterval) does that. Also, autossh is good at keeping connections up.

(But for the ultra paranoid - spiped sounds like a better deal)

<comment><USER3> _in some cases, you want to know that things have disconnected and data won 't be coming through even if it should_

... which is what TCP keepalives are for.

<comment><USER6> First of all - does spiped give you an option to set TCP_KEEPALIVE on its socket? The README doesn't mention it, and if I understand correctly, unless spiped does it, the application has no way to do it either. But even if not - don't rush to add it:

TCP keepalives is the common but practically wrong answer. TCP keepalives kick in after 2 hrs (default), and I've used TCP stacks that wouldn't let you configure it to less than 60 mins. For almost any use over a fragile connection, I'd like to know the connection failed within minutes, not hours.

Just to be clear: spiped gives you the same "disconnection detection" guarantee that the underlying TCP gives you in a local network; if you have a connection to another computer, and it unexpectedly reboots / panics / shuts down, and you don't transmit anything - you'll never know the connection is dead with either a TCP connection or a spiped connection (until you try to send something, OR you've configured TCP keepalive _and_ it's been more than 2 hours).

However, with ssh using ServerAliveInterval and ClientAliveInterval settings, you'll get active detection and immediate notification when the disconnect is detected. (With ServerAliveInterval 60 and default count of 3, it'll take up to 4 minutes). autossh will also give you automatic reconnect (whether you pipe through the main shell or use -L / -R).

Using ssh's keep alive to detect connection problems is a kludge; if you really need this functionality, build it into your protocol. However, if you use it to forward a service you cannot modify (e.g. tunneling HTTP connections from browser to server), I find that it is very useful to let ssh figure out that a connection is borked, rather than wait for hours until the TCP stack of browser realizes that.

In fact, I am ashamed to admit that I've used sshuttle on a LAN just so that I get quick disconnect notifications from a computer that had kernel panics. It's ugly, but it does work.

<comment><USER7> "TCP keepalives kick in after 2 hrs (default), and I've used TCP stacks that wouldn't let you configure it to less than 60 mins."

We were doing some interoperability testing with an IEC-61850 stack, and the vendor's library, set the TCP-Keepalive to 100 milliseconds. Needless to say this caused issues on our 30 kbit links.

</comment></comment></comment></comment></comment></comment><comment><USER8>
      > The simplicity of the code ... makes it unlikely that spiped has any security vulnerabilities.

Famous last words :)

On a serious note - this looks like a really useful addition to the toolbox of "low-level unix flavored tools". I can see this being a simple basis for connecting infrastructure together without exposing potentially sensitive data.

<comment><USER3> _Famous last words :)_

Please audit the code! Just like tarsnap, spiped is eligible for bug bounties.

 _I can see this being a simple basis for connecting infrastructure together without exposing potentially sensitive data._

Yes, that's exactly it. The use case is "I have a bunch of servers and I want them to talk to each other securely". Ten years ago this would have just been a matter of stringing cat5 between them, but Cloud changes that.

<comment><USER9> ... and as recent public revelations have shown, having dedicated cat5 or fiber between your servers/datacenters doesn't prevent attackers from reading that data; this approach would inconvenience NSA more than that.

</comment></comment></comment><comment><USER10> It is part of the Tarsnap bug bounty ([http://www.tarsnap.com/bugbounty.html](http://www.tarsnap.com/bugbounty.html)). When I first heard of the bounty I gave it a shot but could never find anything. I ended up learning from the code, which is priceless.

</comment><comment><USER11> I've been using spiped in production now for a few years, ever since the initial announcement here.

I tunnel Zabbix health monitoring communications to and from the server.

I don't have to worry about setting up users, and each node 'config' is only 1 shared keyfile.

If a node is compromised, I can cut it off with one move ( changing the shared key )

</comment><comment><USER12> Wondering - what's wrong with SSH? Is it considered insecure?

<comment><USER3> Probably easiest to answer this with the blog post I wrote when I released this code: [http://www.daemonology.net/blog/2011-07-04-spiped-secure- pip...](http://www.daemonology.net/blog/2011-07-04-spiped-secure-pipe- daemon.html)

<comment><USER13> >You don't need to be running sshd. Given the relative complexities of the two daemons, it's vastly more likely that your server will be compromised via a vulnerability in sshd than via a vulnerability in spiped. (In fact, if you need to run SSH for the benefit of interactive logins, you're probably better off having sshd only listening on 127.0.0.1 and connecting to it via spiped.)

This is a really bad argument. It may be generally true that increased complexity leads to more vulnerabilities in general, but it's not necessary that increased size leads to a large increase in complexity. Poor software design that involves a lot of strange relationships between components inside of an application leads to vulnerabilities. Unless your code base is so small you can provide formal proofs of security, you can make absolutely no assertions based on code size that your code is more or less vulnerably than larger code bases.

Additionally, the number of attempts to break OpenSSH because of the massive user-base gives it a stronger security foundation than you to imply. Put another way, there are massive economic incentives for hackers to pour hours into finding vulnerabilities in OpenSSH since it's the gateway to millions of *nix systems on the Internet. Has spiped been subject to that level of scrutiny?

As a security-minded person, you should not be making grandiose claims about freshly released software being so much more secure than OpenSSH that it should be used to protect OpenSSH endpoints. Would you trust a newly released symmetric crypto algorithm more than AES just because it performed fewer operations?

<comment><USER14> I agree with Colin. I feel much safer with spiped than I would with OpenSSH, even though my opinion of OpenSSH is reasonably high (I trust it more than nginx, for instance). I'm familiar with both codebases, and spiped is just a lot simpler than OpenSSH.

<comment><USER13> Have you performed a full security audit of the spiped code? If not, the only way you can sanely make that argument is via an appeal to authority, which is probably acceptable given tarsnap's reputation. Is that what you're doing here?

<comment><USER14> Ok, two things.

First, an "appeal to authority" is fallacious _when the authority isn 't relevant_. In a discussion of cryptosystems, an appeal to Colin Percival's authority is a valid argument! It's obviously not dispositive, but it's not something you can simply dismiss; you'd need to rebut it with countervailing arguments. Technically, the authority I appealed to in my comment was my own. I happen to think that's also a valid argument, albeit one requiring fewer countervailing arguments. :)

The term "appeal to authority" is misused about as often as "ad hominem".

Second, if you reread my comment more carefully, you'll see that it pre-rebuts the argument you've made here.

I am absolutely prepared to have a debate about the relative safety of spiped and OpenSSH. Please, feel free to marshall some arguments in favor of OpenSSH. A comparative code review of the two projects sounds like a pleasant way to spend a lazy Sunday.

<comment><USER13> >First, an "appeal to authority" is fallacious when the authority isn't relevant. In a discussion of cryptosystems, an appeal to Colin Percival's authority is a valid argument! It's obviously not dispositive, but it's not something you can simply dismiss; you'd need to rebut it with countervailing arguments. Technically, the authority I appealed to in my comment was my own. I happen to think that's also a valid argument, albeit one requiring fewer countervailing arguments. :)

If you read my comment, you would see that I said it was probably valid in this case due to tarsnap's reputation. I was just clarifying the argument you were making to see if you actually had already performed a code review of spiped. However, an appeal to authority is still not valid (in academia at least), it's just a useful tool to shortcut arguments. When it gets down to the nitty-gritty of talking about showing that something is secure, if something is not dispositive, you can and you _must_ dismiss it without regard.

>I am absolutely prepared to have a debate about the relative safety of spiped and OpenSSH. Please, feel free to marshall some arguments in favor of OpenSSH. A comparative code review of the two projects sounds like a pleasant way to spend a lazy Sunday.

Reread my comment in response to his, you should understand that the burden of proof lies with anyone claiming product X is more secure than OpenSSH. You cannot come in and claim spiped is simply more secure than OpenSSH on an argument of code-size alone. The security community is better than that.

Also, I already gave an argument in favor of OpenSSH in its current state from the economic perspective. There is a nearly limitless treasure chest of computing power and bandwidth available to people who discover vulnerabilities in OpenSSH. In that regard, it's received orders of magnitude more scrutiny than spiped. From the academic side, OpenSSH is a popular target for experiments in static and dynamic analysis because a new automated method that discovers a vulnerability in something like OpenSSH will guarantee citations and top venue.

On a related note, vulnerabilities so egregious that require you to shield OpenSSH using spiped implies that OpenSSH is fundamentally broken. If that's the case, what's the expected method of installing spiped and the symmetric keys on something like an EC2 instance?

<comment><USER14> You're right: there is more incentive to find OpenSSH vulnerabilities than spiped vulnerabilities, and so the absence of OpenSSH vulnerabilities is more telling than the absence of spiped vulnerabilities.

But spiped is so much simpler than OpenSSH that more is going on: it's not merely that fewer people are looking, but that there is less to find.

Look over the history of OpenSSH vulnerabilities and reduce them to the subset that could _possibly_ have affected spiped and you'll see what I mean. spiped benefits from having less mechanism than OpenSSH.

The idea behind deploying spiped is that you leave OpenSSH exposed for the tiny window of time required to get spiped deployed, and then you turn it off. Even if OpenSSH is totally broken, you still benefit from the fact that attackers aren't omniscient. A similar, weaker property is the reason every host running nginx hasn't been owned up.

<comment><USER13> >Look over the history of OpenSSH vulnerabilities and reduce them to the subset that could possibly have affected spiped and you'll see what I mean. spiped benefits from having less mechanism than OpenSSH.

This is true, but if you were using them to solve the same use-cases (fixed tunneling between hosts), how often would those OpenSSH vulnerabilities have been exploitable?

I apologize for arguing with you. The votes my comments are receiving have indicated to me that my input on this subject is not welcome in this community.

<comment><USER14> Breathe. The downvotes you got (I wasn't one of them) indicated that people disagree with you. Probably by default, because they know who me and Colin are.

It's also a useful point that not all of OpenSSH's additional mechanism is implicated when doing point-to-point tunneling. But look at the actual vulnerabilities: some of them are!

<comment><USER13> >The downvotes you got (I wasn't one of them) indicated that people disagree with you. Probably by default, because they know who me and Colin are.

Doesn't that make you sad inside?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> OP here. So quick technical question for those reading this thread since I came across spiped while trying to find a solution to a problem that I believe should be solvable without resorting to spiped or socat.

The manpage for sshd_config says that turning off AllowAgentForwarding still doesn't prevent users from setting up their own forwarders. If I have ssh- agent set up to forward to the host I am connecting to, but it has AllowAgentForwarding turned off, is it possible to set up my own forwarder in sshd without changing having to enable it and reconnect with a new session? i.e. is there a way to get the SSH_AUTH_SOCK unix domain socket on my localhost forwarded to the host machine I'm currently sshed into using only the tools likely to be installed on a typical linux box or is the only way to do it with tools like spiped or socat?

<comment><USER11> If I understand you correctly, the admin of sshd has turned off forwarding.

You'll have to set you your own userspace forwarder if the admin hasn't also clamped down the firewall config too tight.

If they HAVE clamped down the config, you could still invoke netcat on the remote side and use some form of kermit tunneling to get to the remote target side.

<comment><AUTHOR> Not quite. The server is an amazon elastic beanstalk image that comes with it turned off. I can turn it back on after the machine is provisioned, but I want to be able to turn it on before the machine is provisioned so that the npm install with git urls pointing to private repos works.

Basically, once I SSH and I'm root during the provisioning process, how do I programmatically set up ssh-agent for an in progress ssh session so that all future commands have access to the SSH_AUTH_SOCKET on my localhost.

<comment><USER15> That sounds like the wrong way to do it tbh. What about a deployment key?

Not sure if that is any easier on eb though. Some other ideas: [http://stackoverflow.com/questions/13476138/setting-up- priva...](http://stackoverflow.com/questions/13476138/setting-up-private- github-access-with-aws-elastic-beanstalk-and-ruby-container)

<comment><AUTHOR> Tried that. I got it to work, but it's super hackish and brittle. Basically, Github supports deployment keys, but they need to be unique per repo, so if I have many repos I want to clone (for each private npm module) I will need to clone multiple keys. Then since ssh only allows different keys based on the hostname or username, and all git clones are email@example.com, you have to create a script for the GIT_SSH env var to choose the right key based on the value of $2 passed to the GIT_SSH script. The only way a deployment key makes sense is to make a dummy user with read only access to the repos you need, which is yet another undesirable hack.

<comment><AUTHOR> Turns out what I want to do is impossible without something like spiped. I dug into the source of the cli tool and it looks like it doesn't rely on ssh at all. Instead it does all the provisioning through amazon APIs. i.e. Amazon is sshing into the machine for provisioning purposes, not my machine.

Basically, I need to expose my ssh-agent socket to the world via a TCP socket exposed to the world. The server would then install spiped, get the symmetric key that allows it to connect to my ssh-agent-port and set up the SSH_AUTH_SOCK to proxy requests to my machine.

This is still more secure than ever letting your private key ever leave your machine.

While I don't think I need it anymore since I can mount the unix domain socket anywhere, I did find this script useful and think others here may as well:

[https://github.com/wwalker/ssh-find-agent/](https://github.com/wwalker/ssh- find-agent/)

</comment></comment></comment></comment></comment></comment><comment><USER16> It's such a simple and useful idea.

But being tied to what's in OpenSSL is scary.

I have been doing what spiped/spipe does using curvecpserver/curvecpclient.

<comment><USER3> _But being tied to what 's in OpenSSL is scary._

OpenSSL is scary, but spiped only uses a very very small corner of the OpenSSL code. In particular, it doesn't use any SSL code.

</comment></comment><comment><USER17> To check the sha256 checksum on a system with openssl, in terminal find the download and do:

        openssl dgst -sha256 spiped-1.3.1.tgz

<comment><USER18> Note that the SHA256 hashes on the linked website are served over HTTP, which is no security against a MITM. If you use the HTTPS site ([https://www.tarsnap.com/spiped.html](https://www.tarsnap.com/spiped.html)) then the tarball links are also HTTPS (same security). Why are we asking people to manually verify hashes when the hash and content enjoy the same level of security?

<comment><AUTHOR> I should have posted the https link. If a mod wants to edit the url for this, twould be appreciated.

cperciva, why serve http at all or not at least redirect people to https by default?

<comment><USER3> _why serve http at all_

Any sane packaging system will check hashes against known good values after downloading, so using https just opens up more attack surface.

<comment><USER13> If they're not using http, where exactly do the known good values come from?

<comment><USER3> The GPG-signed release announcement.

<comment><USER13> While valid, this is an extremely user hostile response. Requiring administrators to dig up release notes and hoping they actually have your gpg key and know what to do with it is essentially giving the middle finger to admins that don't understand crypto well.

<comment><USER19> Not really, because admins that don't bother to read release notes or to verify GPG keys should probably be using package management systems maintained by those who do.

<comment><USER13> That would be fine if there were never a case where a package management system fell out of date due to a package maintainer not staying on top of things.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> I have been using spiped for years. Works great!

</comment><comment><USER21> Just read the full protocol description - does anyone know why PBKDF-SHA256 is used in steps 3 and 7? As far as I can tell, the input key material in both cases is high-entropy; what does a PBKDF do that e.g. HKDF couldn't?

<comment><USER3> PBKDF2-SHA256 is used with an iteration count of 1, so it doesn't make the computation any more expensive.

I'm using PBKDF2-SHA256 to fulfill the role of "something which has the same cryptographic strength as SHA256, but produces an arbitrary length output".

<comment><USER21> Have you looked at the new SHA-3 for this? Seems like you're looking for something like a sponge function. (It's obviously fine as-is, I was just curious)

<comment><USER3> That would have worked fine. Except it didn't exist yet when I wrote spiped. ;-)

</comment></comment></comment></comment><comment><USER22> Is this for unix domain sockets or network sockets ? - the description of "unix sockets" makes me think the first but the reference to "SSH -L" makes me think it's the second.

<comment><USER23> Both.

</comment></comment><comment><USER24> Anybody to explain advantages and disadvantages of spipes over using TLS?

<comment><USER25> If you have actually tried to implement TLS yourself, there are a lot of places where you can go wrong. There are some places in TLS where it is easy to make implementation errors, and you can't confidently say there are unlikely to be any vulnerabilities in an implementation.

spipes builds upon well-understood primitives and provides a simple, clear, and likely to be correct implementation.

<comment><USER26> That seems to be a non-argument to me: you shouldn't implement TLS yourself anyways. And given that spiped is a younger project than say OpenSSL will mean less eyeballs applied to finding bugs. And the cryptographic primitives spiped uses are available in TLS as well.

TLS and spiped are simply two different tools, for two different purposes. Control only one of the endpoints? You'll have to use TLS. Want to secure communication between infrastructure you control? Check out spiped.

<comment><USER27> Even if you're just implementing TLS using an existing TLS library it's easy to get that wrong. TLS is a pain.

</comment></comment></comment></comment><comment><USER28> Anyone know of any blog posts with some more usage examples? The README is ok, but I couldn't follow the given examples (probably a sign I shouldn't be using it at all).

<comment><USER3> You might fine this useful: [http://www.daemonology.net/blog/2012-08-30-protecting- sshd-u...](http://www.daemonology.net/blog/2012-08-30-protecting-sshd-using- spiped.html)

</comment></comment><comment><USER29> never heard about this tool, thanks for posting. I installed this but was not able to find manpages for this.. any how found instructions in README ..

<comment><USER3> If you define MAN1DIR then the man pages will be installed.

<comment><AUTHOR> What about the MANPATH env var? Is that considered as well?

Either way, `brew install spiped` fails on OSX if $MAN1DIR is set because brew works without sudo and all the directories in /usr/share/man are only writeable by root. Obviously not your problem, but just putting it out there. Is MAN1DIR a FreeBSD env var or is it used by other distros?

I was bummed out that spiped was not in Red Hat's yum package registry. I wonder if it's in the other distro registries.

<comment><USER30> FYI, I just submitted a pull request fixing this in homebrew. They're usually pretty good about merging PRs fast, but if you'd like your manpage right now, you can run:

      brew install https://raw.githubusercontent.com/bbatsell/homebrew/spiped-1.3.1-fixmanpage/Library/Formula/spiped.rb

Edit: 1 hour later, it's already been merged.

      brew update;brew reinstall spiped

<comment><AUTHOR> Most awesome.

</comment></comment></comment></comment></comment><comment><USER31> reinvented stunnel.

<comment><USER23> The author uses stunnel to terminate SSL connections[1], so if he reinvented it, it's because he thought it necessary.

[1] [http://www.daemonology.net/blog/2009-09-28-securing- https.ht...](http://www.daemonology.net/blog/2009-09-28-securing-https.html)</comment></comment>


Why I'm Twittering From Davos Even Though I Run Reuters - <AUTHOR> http://www.alleyinsider.com/2009/1/why-im-twittering-from-davos <comment><USER2> Reuters is having a hard time getting their wire service business model up to date, I think.

Not too long ago they sent a Cease & Desist letter to my employer for _linking_ to articles on their site.</comment>


Introducing VR view: embed immersive content into your apps and websites - <AUTHOR> https://developers.googleblog.com/2016/03/introducing-vr-view-embed-immersive.html <comment><USER2> I read the blog post and the docs linked from github and I didn't see anything about support for VR headsets on the PC. I take it this is VR only when using Cardboard on a phone?

That would fit with Google's approach to VR so far. Cardboard is a neat idea but a pretty bad headset experience compared to Gear VR or the desktop headsets. It would be nice to see Google's VR efforts playing nice with the rest of the VR ecosystem rather than them only supporting Cardboard.

<comment><USER3> Unfortunately right now the only way to do WebVR is Firefox Nightly with about:config changes[1] or a special build of Chromium[1]. Hopefully this does support better HMDs once those are shipping, but if you do want to try WebVR now, there are a bunch of three.js demos that have already been ported over (for various values of "ported").

[1] [http://mozvr.com/](http://mozvr.com/)

[2] [https://drive.google.com/folderview?id=0BzudLt22BqGRbW9WTHMt...](https://drive.google.com/folderview?id=0BzudLt22BqGRbW9WTHMtOWMzNjQ)

<comment><USER4> WebVR works on Chrome for Android too, it's just gated behind chrome://flags

</comment></comment></comment><comment><USER5> Interesting idea but I really don't like the user experience. As I'm reading the post on my phone I notice that the image is wiggling slightly. Try to drag it around with my finger. No dice. Then start waving my phone around and realize what's happening. No, thank you; although it makes sense for someone with the goggles to be able to experience this in VR, I don't think it makes any sense for normal mobile users.

</comment><comment><USER6> Pretty cool that a desktop PC gets mouse drag, a phone gets physical rotation and a phone in cardboard gets stereo. Nice.

</comment><comment><USER7> Reminds me of ipix 360. I remember trying to pirate it when i was in highschool. I guess its cool that we no longer need Java Applets to do these things.

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

</comment><comment><USER8> This has been possible with ThreeJS for quite a while.</comment>


Are we ignoring some valuable aspects of development when estimating? - <AUTHOR> https://medium.com/@christianmaioli/are-we-ignoring-some-valuable-aspects-when-doing-estimates-aa3ca92c4d9 <comment><USER2> Even with perfect information and highly experienced experts, I've found that accurate estimating is so unlikely that it it's basically a waste of time to try for accuracy. Just go with a high level vague guess and keep updating that as you go. (For project/phase estimates not individual small tasks).</comment>


Hurricane LTE-U: Don't Let Wi-Fi Get Blown Away - <AUTHOR> https://www.eff.org/deeplinks/2015/11/hurricane-lte-u-dont-let-wi-fi-get-blown-away <comment><USER3> _Meanwhile, Qualcomm, which is developing the technology, plied journalists with breakfast and lunch in an effort to convince them LTE-U was totally benign._

As much as I like the idea of a bunch of scheming Qualcomm executives sitting around a giant conference table plotting to ply journalists with breakfast and lunch, maybe it's possible they were just being polite hosts?

<comment><USER4> Being a polite host is part of convincing people to feel good about you and what you're saying. That's why there is so much entertaining (dinner, drinks, parties, etc.) in politics, sales, and international relations.

There is also at least one study[1] showing that people who have recently eaten have a more positive impression of others.

[1] Mentioned last night on the show "The Brain" on PBS, which I highly recommend.

[http://www.pbs.org/the-brain-with-david- eagleman/home/](http://www.pbs.org/the-brain-with-david-eagleman/home/)

</comment></comment><comment><USER5> I can assure you that the "bellhead" v. "IP-Everywhere" battles still exist.

As recently as 2 years ago, international telecom exists were lamenting the proliferation of wifi - arguing that local LTE is more efficient than wifi; and handsets should use local LTE base stations instead of wifi.

Be very afraid of this - telcos will take action to make their delivery mechanisms metered and rated.

<comment><USER6> "The Rise of the Stupid Network" (1997) is the quintessential essay on this topic, and unfortunately still relevant today. [http://www.isen.com/stupid.html](http://www.isen.com/stupid.html)

<comment><USER7> In case anyone wants it, I created an epub of it.

[https://r.kyaa.sg/vknoez.epub](https://r.kyaa.sg/vknoez.epub)

</comment></comment></comment><comment><USER8> If LTE-U can coexist so peacefully with other unlicensed devices, then maybe all of the LTE bands should be opened to unlicensed devices and carriers can use the same mitigation measures on all LTE bands to let everything coexist happily.

There, problem solved, I'm sure the carriers will jump right on this.

<comment><USER9> Hm, this is actually a great response. I can't think of a good counter argument. It would be interesting to see someone with more technical or legal experience to comment on the implications of this

<comment><USER8> I think the counter argument is that the carriers must be automatically cutting back their use of the spectrum when they detect other devices, so if unlicensed devices were allowed on the carrier licensed bands, it would reduce spectrum available to the carriers.

Though it seems fair, if they want to eat into the public unlicensed spectrum, they ought to give the public access to their own spectrum.

</comment></comment></comment><comment><AUTHOR> If this ever happens around here, I'm replacing my AP with an even louder one, as loud and disruptive as I can go without violating FCC requirements. I will drown out LTE-U in my area and do whatever it take to disable LTE-U detection on the AP (such as buying out of date APs that don't recognize it).

Qualcomm, who is leading the effort behind LTE-U, belongs to the Wi-Fi Alliance and submits things to the IEEE 802.11 Working Group, and its not like they're not making money no matter what they sell.

Maybe Qualcomm should be removed from the Wi-Fi Alliance and banned from the IEEE 802.11 Working Group if they continue to push for standards and "features" (term used loosely) that damage Wi-Fi.

5.8 GHz isn't even good for long distance transmission, this is why it was given away as an unlicensed block to begin with. So, what the hell?

Not only that, cell phone data already has tons of frequency space; they just keep wasting it on 2G, 3G, non-LTE 3.9G, non-VoLTE voice. It is not my problem that "oh, customers are still using hardware that doesn't support more efficient use of the spectrum"; I own a reasonably up to date LTE phone that can do VoLTE, I did not pay out my ass for one (its an original Nexus 5).

LTE is the first protocol that is meant to be fully backwards and forwards compatible, all previous protocols just muck up perfectly good spectrum. You know what happened when USB came out? Or HDMI and DisplayPort? Or PCI-E? Or SATA and SAS? They all quickly replaced all legacy standards and became the norm in short order. Their collective hallmark is easier and cheaper to produce hardware that has a protocol that is forwards and backwards compatible (something they all share with LTE).

LTE, however? In my town, about half the spectrum is dedicated to non-LTE usage, yet most phones around here are LTE data, with or without VoLTE capability, and the few dumb phones remaining are 3G voice.

You know what that means? 5 mbps or less is the norm for downstream data unless you're right in front of the tower, then I've seen it go past 50 mbps. If they shut off 2G completely, shut off 3G/3.9G data, moved all the VoLTE- capable customers over to VoLTE, and shrank the 3G voice segment down to only what we need to serve the area, we'd be getting 10 or 15 mbps instead of 5.

We don't need more cell phone spectrum, we just need to stop wasting it on ancient inefficient protocols.

<comment><USER10> This is a game you can't win, unfortunately. If the interference gets too much LTE-U phones can just fall back to their parallel LTE connection on licensed spectrum, but your wifi has nowhere to go that LTE can't follow you to.

</comment></comment><comment><USER11> Single sentence summary for any "authority" doing review on this to make a decision:

 _" Wi-Fi devices aren't equipped to recognize the presence of an LTE-U device and don't know that they should only transmit when the LTE-U device has scheduled itself to remain silent."_

and that's why LTE-U cannot be allowed to exist

unless they are just looking for a reason to sell everyone new devices, again

<comment><USER12> Unfortunately that's not a very good argument on its own. Wifi exists in the unlicensed bands in the US and is thus subject to FCC title 47, part 15 rules. This includes the provision that the onus is on the unlicensed transmitter (in this case your wifi device) to gracefully deal with any interference it might encounter.

<comment><USER13> At the same time (from the article):

47 U.S. Code § 333 - Willful or malicious interference

No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this chapter or operated by the United States Government.

This puts some responsibility on the LTE operator to not stomp on WiFi.

<comment><USER14> Also, "The FCC has already said that Section 333 applies to unlicensed spectrum by prohibiting Wi-Fi jamming." [http://www.wetmachine.com/tales-of- the-sausage-factory/my-in...](http://www.wetmachine.com/tales-of-the-sausage- factory/my-insanely-long-field-guide-to-the-lteu-dust-up-part-ii-a-storm-of- spectrum-swords/)

</comment></comment></comment></comment><comment><USER15> Here's my conspiracy theory for the day:

1) In the long-term, regulation is to the benefit of the incumbents.

2) Most in technology prefer light regulation

3) If you act as a "bad citizen" in such a way to piss off people you can change #2.

Thus the result of acting out is more regulation, which increases your costs, but also acts as a significant barrier to entry for future competitors.

</comment><comment><USER16> Our city and parts of the county have 5.8ghz Ubiquiti equipment serving internet for thousands of residents provided by our local WISP. I also rely on this service myself since I'm just outside of city limits, this would surely be a big problem for everyone. I get a solid 10mbps connection, much better than our only other option 1.5mb DSL.

</comment><comment><USER17> This is Sherif from Qualcomm. I know LTE-U is a new concept so there's a lot misconceptions around it. I'll be happy to answer your questions.

<comment><USER18> OK. Will LTE-U devices transmit at the same time as Wi-Fi devices and impair their bandwidth?

<comment><USER17> LTE-U will first seek out channels with no incumbent Wi-Fi (or LTE-U) access points. If no clear channel is found, it'll seek the least occupied one, then evaluate how many other transmitters are using it. It'll then use the channel for a an amount of time proportional to that total number of transmitters. So if sharing with 2 other Wi-Fi access points, it'll take one third of the time. The result is that the impact of LTE-U on Wi-Fi is no more than the impact of Wi-Fi on Wi-Fi.

<comment><USER19> I would argue that the impact of LTE-U on Wi-Fi is actually greater than that of Wi-Fi on Wi-Fi, despite what you have pointed out. It is true that LTE-U operates on a fair time-share basis (TDMA [1]), however the problem here is that LTE-U unfairly transmits while Wi-Fi stations are transmitting, giving absolutely no regard to the actual channel usage by Wi-Fi stations. Wi-Fi does not work on a time-share basis, it operates on a "don't talk while I'm talking" basis, and since TDMA is a different way of communicating, Wi-Fi stations don't know how to avoid collisions with LTE-U stations. From the perspective of a Wi-Fi station, an LTE-U station is just like a leaky microwave oven, there is no way to avoid radio collisions with it.

There isn't a way for Wi-Fi stations to know what TDMA time slots are "free," how long those time slots are, and there isn't a way for Wi-Fi networks to "sign up" for a time slot with the TDMA networks. The TDMA networks just decide to talk at some predefined interval without consulting the Wi-Fi networks to see when they would like to talk. This does not sound fair to me - it's kind of like saying "I'm going to yell very loudly once every minute. If it interrupts the conversation that you are trying to have then too bad for you. But I'm not going to yell when my friends are yelling, because we have an agreement in place."

Normally, Wi-Fi stations use CSMA/CA [2] to avoid transmitting when other Wi- Fi stations are transmitting, which overall reduces the number of lost Wi-Fi frames for everybody. This is what I mean by "don't talk while I'm talking." So the impact of Wi-Fi on Wi-Fi is materially lower than the impact of LTE-U on Wi-Fi simply from a statistical standpoint.

In addition, LTE-U only transmits when it detects other Wi-Fi transmitters. However, due to the hidden node problem [3], not all Wi-Fi stations that are using the channel can necessarily be detected by an LTE-U station, but the LTE-U station is still able to interfere with them. So there will be some quiet Wi-Fi stations that the LTE-U station can't see at all, and when the LTE-U station decides the channel is mostly empty and blasts its signal there, the quiet Wi-Fi station will be disproportionately overcome with interference. Again, the interference would be TDMA interference, but the Wi-Fi access points would not know how or when to avoid TDMA collisions, so the interference would be worse than Wi-Fi interference.

Normally, with Wi-Fi and CSMA/CA, the gaps in the louder station's transmissions would be good opportunities for the quieter station to start transmitting, allowing them to sometimes take turns even though the louder station cannot hear the quieter station, and the hidden node problem would be mitigated as best as CSMA/CA is capable of doing so. But with TDMA interference, there isn't any cue that Wi-Fi can take which indicates that now is a good time to transmit without interference.

This could all be avoided if LTE-U didn't solely operate on a TDMA basis, but also ceased transmitting (or skipped time slots) while Wi-Fi networks are transmitting.

LTE-U risks starting or worsening a "loudness war" where other unlicensed spectrum users decide to buy louder and louder unlicensed equipment up to (and possibly past) the legal limit, because their networks are unusable with too much interference otherwise.

Combine this design decision with the interest that wireless telecommunications companies have preferring their LTE networks over the well- being of Wi-Fi networks, and it starts to paint a sinister picture - <USER2> telecommunications companies might be attempting to deliberately interfere with unlicensed Wi-Fi networks in order to promote their own networks and equipment as being superior.

[1]: [https://en.wikipedia.org/wiki/Time_division_multiple_access](https://en.wikipedia.org/wiki/Time_division_multiple_access) [2]: [https://en.wikipedia.org/wiki/Carrier_sense_multiple_access_...](https://en.wikipedia.org/wiki/Carrier_sense_multiple_access_with_collision_avoidance) [3]: [https://en.wikipedia.org/wiki/Hidden_node_problem](https://en.wikipedia.org/wiki/Hidden_node_problem)

</comment></comment></comment></comment><comment><USER20> Sounds bad, but I would like to know if there is a technical benefit excluding Listen Before Talk in some countries. Why would an engineer possibly want to turn it off, given that the support has to be developed for those countries that require Listen Before Talk anyway? (The evil megacorp financial reasons are obvious, but let's pretend for the sake of discussion that they are not stupid enough to think that breaking Wi-Fi networks across the country/world will have no PR repercussions -- it will cause massive hassle for everyone.)

<comment><USER21> The throughput and latency are probably better if you can just go ahead and transmit when you have something to send.

</comment></comment><comment><USER22> Right now, HAMs in the US can run personal/private GSM as long as they do it in that little overlapping part of 900mhz band that euro GSM shares with an amateur band...

Do I understand that one could also run a personal/private LTE in this 5.8ghz band ?

<comment><USER10> Pretty sure the answer is no, because all the signalling to negotiate the use of LTE-U happens over licensed LTE frequencies - so unless you're a ham that happens to be able to transmit in one of those bands, no dice.

</comment></comment><comment><USER23> Why can't they produce some samples and let the FCC and an independent body of engineers determine if there really is going to be an issue?

Sending out letters with promises doesn't mean squat.

</comment><comment><USER24> Why not just make it all licensed? I imagine we could solve the coordinatin problem in some fair manner potentially even letting people get payed for not using spectrum.

Establish some kind of protocol for negotiating where in devices acting on behalf of interested parties (you, your neighbors, the local telco) continuously negotiate for spectrum and power. The winner for a slot pay the other parties for their slot.

It's not like violators can hide, so it should be pretty easy to enforce compliance.

<comment><USER25> This already exists. The modern unlicensed wireless protocols all play nice with each other using some form of carrier-sense.

The problem is that LTE-U is going to use a TDMA scheme, and, according to the article, will not include any collision avoidance. This means that it may start transmitting at the same time your wifi is transmitting.

<comment><USER24> My point being that a little conflict with my wifi might be ok as long as it's a fair transaction. If I'm freeing the spot for sale and get payed. It would also replace bureaucracy with economics instead, which should be good for optimizing utilization.

The main difference compared to carrier sense is that I'm suggesting a competition based negotiation, not cooperation based. Instead of waiting for a free spot, you buy the spot.

If the unlicensed spectrum is a commons, the problem with uncooperative commoners like this LTE-U thing looks an instance of the tragedy of the commons. In a sense I'm suggesting a form privatization.

</comment></comment></comment><comment><USER26> I wonder how much it'll be used once this tech start's growing:

[http://www.fiercewireless.com/tech/story/fcc-votes-adopt- new...](http://www.fiercewireless.com/tech/story/fcc-votes-adopt-new-35-ghz- spectrum-sharing-plan-innovation-band/2015-04-17)

</comment><comment><USER27> So if towers start broadcasting on 5.8, won't they have so many more devices to talk to no wifi stands a chance?</comment>


Adobe Buys Swiss Company Day Software For $240 Million - <AUTHOR> http://techcrunch.com/2010/07/27/adobe-buys-day-software-240-million/

<comment><USER2> Interesting tidbit from their about page "Day Software has been a leading force in the open source community. Day Chief Scientist Roy Fielding was co- founder of the Apache Software Foundation, author of the Apache Software license, and creator of the Apache web server." - Roy Fielding also being the PhD behind REST

<comment> jc-denton Wow didn't know this..

</comment></comment><comment><USER3> Day Software also contributes to a variety of Apache projects, such as "Jackrabbit".

</comment><comment><USER4> Wow that is big news. I hope they don't hollow out the company to just get the people and the ideas behind the product. it's great (but has also some caveats).

Their Nosql idea has too great possibilitys.

And of course as stated by Kris they use lots of opensource in their Product.

</comment><comment><USER5> Thomas Mueller, the guy behind H2, an all-Java open source RDBMS, also works for Jackrabbit.</comment>


Skip the Post Office, Use Shyp - <AUTHOR> http://blog.geteasypost.com/post/52239161920/skip-the-post-office-use-shyp <comment><USER2> "Currently, for a consumer or small business to send packages the following needs to happen: buy packing materials, pack the order, drive to shipping carrier, wait in line, and pay."

Not really. You do need packing materials.. but Endicia, Stamps.com, and even the USPS website will let you print postage. And you can request a free pickup through the usps website.

That's your real competition...

<comment><USER3> Co-founder of Shyp here.

Absolutely! However USPS only does pickups from 10-2 M-S. You need to be there or leave the package outside.

We will be soon adding support for UPS, Fedex, Ontrac and a bunch of other regional shipping company. Ship through Shyp and we handle everything.

<comment><USER2> Maybe in SF.. I'm in Denver, and I've had USPS pickups as late as 6:30pm. Downside was always you couldn't be completely sure at what time they would show up.

I've also heard some UPS Stores will pickup, package, and ship packages for you.. but it's up to the store (they're independently owned).. don't know how widespread that is.

I really don't have anything else to add... It's an interesting idea.. How compelling it is depends on the price I would think.

</comment></comment></comment><comment><USER4> The recent surge in physical shipping startups is interesting, but concerning as well. How can these new companies with limited funds afford to be sending drivers around to pickup packages and visit various locations? I think yesterday there was a company that would come pickup your mail from your mailbox. How is that possibly sustainable? And how can it scale to anywhere beyond maybe San Francisco? It just seems like a very lofty goal.

<comment><USER3> By being profitable on every transaction from day 1. I can't speak to other shipping startups but we make good margins after paying our delivery drivers.

If this works in SF it will most likely work in other major cities. Shipping stuff sucks everywhere.

<comment><USER5> Are you seeing more traction with in city deliver (so basically courier on demand for individuals) vs. people who want to eliminate the hassle of shipping out of the city?

<comment><USER3> It's been 90/10 shipping out of city.

</comment></comment></comment></comment><comment><USER6> What's with all the snail mail startups / projects in the last few days?

Did USPS open up some regulation or something, what's going on?

<comment><USER7> The rise of Fab.com thefancy.com and the other design websites that sell physical products that the owners ship have motivated startups to make fulfillment more efficient I think.

Fulfillment is the biggest pain in the ass of a business. You won't understand until you have to do it yourself. Even 10 packages can take an hour from beginning to end. So a few startups caught on and the rest were inspired to offer solutions as well.

I personally can't use Shyp because I have a sweet & easy setup already.

1) I have all my shipping supplies in the basement (boxes stacked to the ceiling).

2) I pack my orders (from DayOnePP.com) and buy postage using Stamps.com and print it out on sticky labels using my laser printer.

3) As long as 1 box is Priority Mail the USPS will pick up for free the next day. She's usually here at 3pm so I know when to be ready.

4) If not, there's always a post office within 5 minutes that has a 24/hour package drop off container. I just run through that before work and drop off all the boxes I've got.

It literally cannot get easier. I don't wait in line for anything and still get the cheapest prices on postage by using the online discounts that stamps.com(& PayPal Shipping & Pitney Bowes Smart Postage & Endicia offer) .

<comment><USER6> I asked because when I did a lot of shipping I had the same setup that you just mentioned. I'd just use the paypal hookup to print shipping labels for no additional cost.

Beyond actually packing and shipping the product I don't see what else there is left to solve.

</comment></comment></comment><comment><USER8> I feel that doing an API this way begs for a middle man to make an app that normal people can actually use to do shipping in their business.

Why, if I want to ship things to people as my business, would I implement some software myself using this rather than buy an existing offering?

Am I missing something? Shipping and accepting credit cards are completely different, I know this API concept works for Stripe, but I fail to see how it works well for shipping.

<comment><USER9> Just as with a credit card API, you would integrate the ability to purchase & print postage within another application.

I work on an internal company application and it would be great if people could purchase & print postage from within the application.

<comment><AUTHOR> Exactly -- the underlying APIs are painful to integrate, just like with Stripe.

Drop me a line at j at easypost dot com and I'd love to see how we can help

</comment></comment></comment><comment><USER10> Another downside to your app is that it's on the iPhone platform, and I use Blackberry.

If you had a way for me to use a normal digital camera with my PC it would help get me on board.

There was some other new service here on HN recently that was called 'Sold' for selling stuff but it only worked on a certain platform I didn't have a device for, too- so I guess its not uncommon for startups to exclude whole market segments by device ownership.

<comment><USER5> I don't think it's a matter of them choosing to not work with Blackberry users, it's a matter of trade offs between time and resources. As a startup, you may only have time to build one great app for one platform and iOS was the chosen one.

To come to that decision, it was probably a factor of what you know and also some insight into the customer base. For example, maybe iOS users tend to be more likely to pay a premium for convenience or that in San Francisco, iOS penetration is higher than Android, etc etc.

If the product picks up traction, I will bet that their next move is to port to Android, then web, then maybe ... maybe windows phone and blackberry.

</comment></comment><comment><USER11> I'm still waiting on my invite. I saw some ads on FB advertising it and decided to try, but have been waiting since. I hate the Post Office and would love to this us.

<comment><USER12> Glad to hear! Right now we're slowly taking on beta users, but we'll be ramping up significantly over the next while. Looking forward to having you on board and getting your feedback!

<comment><USER13> This is an awesome idea. There is room for other shipping companies for sure. I hate using ups, always late over priced. Bring on A new company and lool forward to trying it out!

</comment></comment></comment><comment><USER14> Question: How are you going to protect my shipments from being damaged if they're not packaged? Or do you package on my site?

<comment><USER3> We have custom bags that have heavy padding on the inside. We have designed them to transport fragile items. If multiple items are going in the same package, we bubble wrap each individually on site.

We take these bags with contents to our warehouse where we professional package all items for transport.

<comment><USER15> And if it is damaged on arrival, who is liable, you or the shipping company. Who do i have to deal with to get paid for my broken item?

<comment><USER3> We inspect every item at our warehouse. If it was damaged during transport to us, we cover 100%. If it is damaged from us to the destination, it will be up to the shipping company. We offer insurance through USPS.

We are looking to cover round trip but still seeing if that is economical for us.

</comment></comment></comment></comment><comment><USER16> the spelling of this name bothers me..</comment>


Comparing LibreOffice Versions: AppImage, Flatpak, and Snap - <AUTHOR> http://www.ubuntubuzz.com/2019/06/comparing-libreoffice-62-versions-appimage-flatpak-snap.html <comment><USER2> >LibreOffice for GNU/Linux nowadays is available in 3 different universal formats, as alternative to the native format (DEB and RPM). This is an advancement that benefits us all greatly.

Not sure I understand the thinking behind this statement. If LibreOffice is native to a distribution wouldn't you be better off just leaving it as it is? The three methods are more applicable to third party programs...

<comment><USER3> Some version of LibreOffice is native to a distribution. Those new formats have benefits, including the ability to automate the processes of updates (mostly thanks to better tooling as they are newer), the ability for confinement, etc.

<comment> yjftsjthsd-h > including the ability to automate the processes of updates

... What exactly will it do that's better than being included in `apt upgrade`? I do _not_ want to go back to the Windows way where every stupid application insists on running its own little auto-updater in the background.

</comment></comment></comment><comment><USER4> In the article the author times the startup speed for each installation method. It's a known issue that Snap installed applications are slower to execute for the first time than they are subsequently. It's not clear from the piece if the timed execution was the applications first run or not.

<comment><USER5> Is that the first time per installation, or the first time per boot?

I just tried starting the gnome-characters app, which I have installed via snap and via apt. The snap-installed app boots in around 6 seconds after restarting my machine, and then in about 3 seconds afterwards (I'm just counting the seconds in my head). By contrast, the apt-installed app boots well under a second.

<comment><USER6> My god, doesn't that amount of time bother anyone? 3 whole seconds is an eternity on modern hardware.

<comment><USER7> It probably bothers some people but it does not bother me. I'm on relatively slow hardware. I use a (second?) gen i5, but without an SSD and without a GPU. My laptop is fine for programming, even gaming (CS:GO, CS:S both work! CS:GO admittedly on 1080p but low graphics).

The thing is that I've never used anything faster than an i7 + HDD (with GPU). So when my old one died, I just started using my ever so slightly slower laptop as main device.

I firmly believe that as long as you have not experienced the difference (which I haven't) it does not bother you. Applications don't start lightning fast, when I open the terminal I need to wait a second before I can start typing. So I start Spotify, Firefox alongside my terminal and after ~10 seconds I'm up and running for the rest of the day.

I'm not that bothered about waiting 10 seconds each day.

<comment><USER6> You really should be. I am continually amazed at how, even though computers have become orders of magnitude faster since the early 90s, everything still feels pretty much exactly as slow.

Let me put it this way: A 2nd gen i5 can execute about 6 instructions per cycle per core. At 3Ghz, that's 18 billion instructions every second or 5e-11 seconds per instruction. If each of those instructions is a second to the processor's subjective experience, then 18 billion of them is about 570 years. It takes 3 times that to startup an application for typing text into a document.

I didn't even take multicore into account.

</comment></comment></comment></comment></comment><comment><USER8> I find AppImage files quite annoying, I must admit. I understand that it's annoying packaging for all the different Linux distros, but this doesn't feel like the solution. Maybe renaming them and dumping them in /usr/local/bin would make them integrate better with the OS, but I usually just avoid them.

Flatpak has been quite nice when I've used it, if a bit more awkward to figure out first time.

Snap is fine, but the actual publishing side of it I found quite confusing and arduous when I tried it, so from a developer point-of-view I would probably avoid it (unless it improved a lot in the last year).

<comment><USER9> Why do you find them annoying? I love them. Every application is just one file that I can freely move and copy around, can't be any simpler than that.

<comment> yjftsjthsd-h Take a dozen such applications, then have a security vulnerability show up in a core library. Still simple?

<comment><USER6> Yes, it just isn't "secure" as far as the security-for-the-security-gods types are concerned.

<comment><USER9> It depends on how often the stuff in the packages gets updated, not on the package format.

</comment></comment></comment></comment></comment><comment><USER10> Redhat and Ubuntu should bury the packaging hatchet and arrive at a single packaging format. Doesnt matter if it is snap or flatpak. That would have far reaching ramifications for the adoption of Linux.

<comment><USER11> A Linux distribution's work _is_ the packaging format and tools - deciding to use a common one would basically be shutting down the other distro.

<comment><USER12> Eh... it's a _lot_ more than that. It's the specific packages themselves, and how those packages are built, and how the OS is structured, which versions of libraries are used, how certain common tools are named (think python vs python3). The philosophy of different distros can be radically different. Startup environments can be completely different. Defaults and config in different places. Packages are patched differently. Libraries named differently (think dynamic linking to specific library versions). Init vs. systemd. Wayland vs. XWindows. Some distros even eliminate the distinction between /bin and /sbin. If RHEL, for example, adopted apt, a RHEL pkg likely won't work on Debian. That's why Snap, Flatpak and AppImage are what they are: completely self-contained or statically linked with no dependence on system libraries or image trees.

</comment></comment></comment><comment><USER13> I still don't get the difference between Flatpak and Snap.

I get that AppImage is a self contained executable. Fine - makes sense to me. The others... I've got both installed on my Ubuntu 19.04 box and I really have no idea why I'd choose one over the other, or what the projects are trying to do that's so different from each other.

Sure, competition is good - but wouldn't pooling resources be better?

<comment><USER14> Flatpak and Snap have some different approaches, both come with pros and cons.

The first difference is centralization vs. decentralization. Snap is centralized, there's no way to make your private repos fully under your control. If you want private snap repo, you must talk to Canonical. From the user perspective, there's are no competing snap repos, only the Canonical one. They also support update pushing, so users will get updates whether they want them or not. This is a huge departure from the way apt/yum repos were managed.

This mirrors in the runtime support: snaps have centralized core16 / core18 runtimes or whatever Canonical comes with. Flatpak runtimes are decentralized and everyone can make one. You can use org.freedesktop.Platform, org.gnome.Platform, org.kde.Platform, maybe in future there will be org.centos.Platform or even something entirely different.

Flatpak focuses on desktop - their main method of app integration are .desktop files and dbus names. Snap allows arbitrary applications, including services or cli apps. This impacts the visibility from outside the sandbox: flatpak uses namespaces, so outside you won't get to see the private bind mounts that the containers use. With snap, your mount namespace is polluted with the squashfs mount points.

For sandboxing, Flatpak uses namespaces and secomp, with optional SELinux. Snap requires AppArmor, but packages with confinement: classic are not sandboxed at all.

Flatpak uses OSTree to store the app, framework or addon files. OSTree is often called _git for binaries_ , it is content-addressable repository with checkouts and pulls. Snaps are squasfs images.

Things they have in common: both are sandboxed (except classic snaps), that's why the first launch is slower than unsandboxed applications. There are some things, that are being done, for example font caches are being created, that the unsandboxed apps do not have to do, because the host environment already has them. Both allows you to target a specific runtime/SDK, so there's no surprise for the app at install or runtime. Both have a permission system, that can control, how the app can interact with other apps or host, though the permissions currently defined may differ.

<comment><USER3> Snap is not "centralized". It comes with a default Store, and this helps most users that require modern package management.

If you want to distribute manually your .snap packages, then you can certainly do so.

For example, the libreoffice snap is easily available for download at [https://uappexplorer.com/snap/ubuntu/libreoffice](https://uappexplorer.com/snap/ubuntu/libreoffice) The recipe to create the snap package is shown on the same page. You can recreate the snap package and then keep it for yourself. Or, upload it to your website and share with your friends.

After you download the .snap package, just click on it and it will prompt you to install it.

What you do not get with snaps, is the source code of the Ubuntu Store. Most likely, if someone is really interested to replicate the store, I believe it is easy to reverse-engineer, then create a reference implementation.

<comment><USER14> That's somewhat disingenuous comparison.

Snap, as an ecosystem, includes not only the .snap package, but also the remote side, equivalent to apt/yum. Even if you do not want the store equivalent, just plain old repo, you cannot do that with snap. You would have to replicate all the add repo/check for updates/install/update logic on the client side too - snap won't allow you to register your repo, _even if you had your server side solved_ (side note: for apt, yum, flatpak, plain old httpd server is enough).

Therefore, when comparing with flatpak, which does allow remote- add/delete/info/ls/update, snap is centralized. The "you can code it yourself" is not an argument; you can code yourself equivalent to many other proprietary systems, and that does not make them open or less limited.

</comment></comment></comment></comment><comment><USER15> The key here is which of the formats can I trust the most? Which one of these are likely to betray me?

<comment><USER3> You will most likely get a malicious AppImage from some website because there is no default central store with such packages.

You could argue that there is a freedom with AppImage that you are not bound to a Store. But that would not be correct, because you can self-host both snaps and flatpaks, if you really need to.

With snaps, you have more fine-grained security privileges. For example, "httpstat" [1] is a network utility to benchmark the access to a website. As a utility, it only requires access to the network. With snaps, the packager can only permit access to the network, and no access at all to the user's files or anything else.

1\. [https://github.com/davecheney/httpstat](https://github.com/davecheney/httpstat)

<comment><AUTHOR> > is no default central store with such packages

And this is limitation of Snap and Flatpack - both stored in centralized stores.

AppImage is fully independent from any centralized stores, so developers could distribute own apps as AppImage-package _directly_ to users.

<comment><USER3> I said that there is no "default" central store for package in AppImage. Which means that there is a "default" central store for snaps and flatpaks.

And if you do not like the "default" central store, you are free to distribute yourself the individual snap or flatpak package. Just like with AppImage.

<comment><USER6> Sure... by making the user setup the equivalent of a PPA. AppImage's advantage is that you can mail it to them on a CD and they can just run it _from the CD_.

<comment><USER3> Damned if you do, damned if you don't.

Regarding the reference to "like mounting the CD ISO" for AppImage. All three of them actually mount one or more filesystems in order to install the package.</comment></comment></comment></comment></comment></comment>


HN takes 5secs to "Collapse" any of the replies from Trump's win - <AUTHOR> Reading https://news.ycombinator.com/item?id=12907201 I was really annoyed by the fact that it takes ~5secs to "Collapse" any of the Replies.
It left me wondering: is it possible at all to make it better? Is it the result of lousy programming? Or is the thread just too big and as such there's  not much to do?
http://i.imgur.com/xiPcxBd.gifv <comment><USER2> Collapses are persisted across logins. My guess is that they collapse once they've heard back that the collapse was committed. If HN is slow to respond to requests (like it is for me right now), this might be the cause of the issue.

If my guess is correct, it could probably be changed to optimistically collapse.

</comment><comment><USER3> [http://www.sli.mg/p08qw0](http://www.sli.mg/p08qw0)

One collapse for 700 comments processes 90k elements...it could be better implemented. But seriously, how often is this an issue? Probably now worth the programming effort.</comment>


Blocked Sites is discontinued - <AUTHOR> http://support.google.com/websearch/bin/answer.py?hl=en&answer=1210386 <comment><USER2> Not surprising, as the feature hasn't worked for quite some time, despite still being available to configure within your settings. I am disappointed however, because there are quite a few sites on the Internet that I would much rather not see at all, ever again. They are the noise in my search for signal in my Google search results. And the entire point of switching to Google way back in the day was the quality of their search results versus what was available in the late 90s.

Being able to personally fine tune those results myself, outside of what a robot thought to "personally" customize my experience to, was a great feature. Suggesting I use a third party plugin for a browser I don't use is hardly a compromise or a solution, and does nothing for my Google search results on mobile platforms where that plugin is not now nor will likely ever be available.

<comment><USER3> Personal Blacklist is an official Google extension, it just doesn't sync with anything or save to a database. At least for my purposes, I don't need it anywhere but my desktop machine to help out in result pruning (experts exchange, fixya).

Their offered download link doesn't even work for me, it just notifies me of its shutdown.

<comment><USER4> _> Their offered download link doesn't even work for me, it just notifies me of its shutdown._

After you go to that link and read the notification, there is another link to download the blocklist as a plain-text file. Mine contained a number of domains I've added during the years.

It's quite interesting to see all the domains I've blocked so far :)

<comment><USER5> Mine was surprisingly short..

www.w3schools.com

<comment><USER6> Well I had all those sites that scrape StackOverflow added to my list.

I love that SO uses a CC license but it does have some unintended consequences.

<comment><USER7> Is there a public list of such site? I think I'd find it quite useful (for my own blocking).

<comment><USER6> I don't think there is. I did it on a case-by-case basis.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I guess I need to go back to manually appending "mdn" to all my html/css/js- related queries. How much longer is w3schools going to stay at the top of those results?

EDIT: Actually, it turns out I've been using the linked Chrome extension (went to install, discovered it was already installed). I just conflated the two services and forgot about the extension. So to make this productive, I recommend this extension. I haven't seen w3schools in months.

<comment><USER9> _/me straightens DuckDuckGo independent evangelist hat and nervously rings doorbell_

"Judging from your comment, you sound like the perfect user for Duck Duck Go!

If you set DDG as the default browser for chrome/ff, you can search mdn with just '!mdn foo'. Also at your fingertips is searching !jquery (and hundreds of other search shortcuts)

DuckDuckGo is great and makes searching super productive!"

 _/me smiles eagerly_

<comment><USER10> Can I ask you why you see DDG as the perfect alternative to google? One would think that if you are concerned with the sort of things google is doing, you would bank on an open source search engine, so this sort of thing doesn't just repeat itself.

<comment><USER11> I have both YaCy and Seeks (distributed open source search engines) in my FF search bar, but the results are really... disappointing. I just get good results with DDG.

DDG's commitment to privacy and not bubbling, etc. I do not believe are going away, it's their biggest selling point.

Besides, as long as RMS is demanding that DDG be the default search engine in the GNU web browser, it's good enough for me.

</comment></comment></comment></comment><comment><USER12> This really sucks for me because it means I'll have to see experts-exchange results again.

Why is Google shutting every secondary project/feature down right now? Reader, labs, blocked sites, code search... Any engineers able to weigh in on how this is affecting innovation or the 80/20 policy?

<comment><USER13> Experts exchange stopped showing up in the results back when Google released the new indexing engine over a year ago. You should be fine.

<comment><USER14> I still see it sometimes. Meanwhile, Quora is in the works to become next EE...

<comment><USER15> I don't understand this comment. Quora doesn't show up in results bc they're not in the index, it's a private site. Unless that's changed?

<comment><USER16> They seem to be showing up for me. I don't have any recent organic examples, but here's query for one of the most popular threads, and the quora thread is the first result:

[https://www.google.com/search?q=How+do+I+get+over+my+bad+hab...](https://www.google.com/search?q=How+do+I+get+over+my+bad+habit+of+procrastinating)

What do you mean by "private site"?

The other objectionable/EE-like thing about it is how it hides the answers unless you log in. That really sucks.

<comment><USER17> EE never hid their answers. They were only obfuscated. First[1] they made it look like the page ended, but you could scroll further and get the answers. Later, I saw that they had a section that looks like the answers, but all of the text was blurred. Again, if you scrolled past the 'end of the site' you could still get to the answers.

Looks like Quora gives you the question, and the first answer, but all other answers are Private-Only.

[1] I think that in the beginning they may have _really_ hidden their answers, but were forced to actually show them by Google.

<comment><USER18> If you add ?share=1 to the end of a Quora URL you can get the full content.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> > To block particular sites from your search results, we recommend the > Personal Blocklist Chrome extension from Google.

Because, you know, everyone using Google also uses Chrome and only uses it on one device.

<comment><USER20> Does someone know of a Firefox extension achieving the same result?

EDIT: just found this Greasemonkey script <https://userscripts.org/scripts/show/33156>

</comment></comment><comment><USER21> I find both its birth and death interesting. The birth because the fact that you could mark sites as spam was one of the early talking points at Blekko, the back end architecture of our engine includes a 'selector' mechanism (slashtags) and maintaining a personal 'spam' slash tag came along for free. Its one of the features I continue to use.

And then it showed up as a feature in Google's results which I found interesting because having worked at Google and had the 'deeper than non- Googlers, not as deep as someone in the search group' classes on how the two services that made up Google search at the time, I had a feel for how much lubricant it would take to squeeze that feature into the existing pipeline. It made me wonder if Google was following _us_ :-)

The death of it is also interesting, because having it in the browser as a plug-in vs the results means two things; You can't offer it as a service to your partners, and you can't know apriori if you're sending junk. If Blekko's partners say "We'd like to use your index but we don't want any results that include x,y or z" we can do that but that is at the API level with results coming right out of the index filtered by a 'negative' slashtag, but its unclear if anyone can (or does) use Google's index in that way (unlike BOSS for example). On the browser side, since you don't know what the plug-in is going to kill, how do you select the 10 documents to send? It makes me wonder that if you're doing a search in a highly contested search (like 'weight loss') and Google can't know that the 10 blue links it is about to send you are all spam (and on really contested keywords this is not uncommon) are you left with just sponsored links and no organic results?

'Panda' update all you want, even Google now admits they are adding staff to curate results (Microsoft/Bing had already gone public with their 'editor's choice' announcement). This is a good thing, but it only covers half the situation. At Blekko we got flamed by a user for not having any 'alternative' medicine sites in our 'health' slashtag, which started a conversation with that user about creating their own slashtag with all of those web sites that were unfairly penalized by the medical establishment just because their methods and claims weren't the product of some 'big pharma' company. But they could (and I believe they did) create a slashtag of all those 'hidden' sites and they got great search results for them. Reinforcing to me and others that 'spam' can be relative, and really it has two sides, user and index.

So pondering this move on Google's part makes for interesting reading.

<comment><USER3> I think it'd be illogical for Google _not_ to in some ways compete with alternatives, like Blekko in this case. Google's core business is search, and in the early days, it was this very naive behavior that allowed Google to sneak right under places like Inktomi. Just because a search engine starts small doesn't mean it can't gain traction or market, and if it has compelling enough features, it'll happen in a heartbeat.

I suggest reading "I'm Feeling Lucky" by Douglass Edwards - the early chapters describe a lot of Google's anxiety of being killed by other search engines for one reason or another. It helps to explain why they'd be quick to adopt new strategies to keep results fresh.

<comment><USER22> I'm not sure google is even clear about what its core business is, these days. It really seems quite clear that they've abandoned much of the approach and focus on being _the information_ finder to now being the social-network wannabe.

It's as if something flipped 180 degrees - they went from being the company that wanted to help _you_ find out about everything to being the company that wanted to find everything _about_ you.

<comment><USER23> Google's core business is advertising.

<comment><USER24> Anyone who disagrees with this other Jacques is invited to take a squiz at Google's annual reports.

Any of them since the introduction of adwords and adsense. It doesn't matter which. They all basically read the same.

<comment><USER22> Indeed – perhaps I was wrong to say that they don't currently know what business they're in – rather, they _haven't_ known and recently, they've re- aligned around a singular strategy focused on that.

The problem is that for so long, they built their public facing brand on a completely different premise and image. Therefore, as they've re-aligned, they're facing a bit of cognitive dissonance in the minds of their products (err, the public).

</comment></comment></comment></comment></comment></comment><comment><USER25> This feature has been discontinued for a few months now. I'm surprised nobody posted this until now.

I actually have found the plugin to be mostly adequate. There aren't a ton of sites that I feel deserve to be blocked from my search results, so syncing isn't a gigantic problem. I do find it annoying that there is a link added to each and every search result to block the site, but it might be useful if I decided to be really picky about my results.

<comment><USER26> I thought it was discontinued a while ago as well, but it was still in limbo as of late January of this year[1].

[1]: [http://searchengineland.com/google-block-sites- feature-14640...](http://searchengineland.com/google-block-sites- feature-146409)

</comment></comment><comment><USER27> Back when the Chrome plug-in shipped (it preceded Blocked Sites by a bit) I compiled an extensive list of content farms as a starting guide for people wanting less spam in their SERPs. If you're migrating over to the extension it's worth a look (and as always, any new suggestions for the list):

[http://www.jongales.com/blog/2011/02/14/list-of-content- farm...](http://www.jongales.com/blog/2011/02/14/list-of-content-farms/)

</comment><comment><USER28> This sucks because the Chrome extension has a noticeable lag before the results are removed. I often accidentally click on a W3Schools link before the extension kicks in, and then wonder why it even came up in results at all.

</comment><comment><USER29> Removing a feature that fixes a major shortcoming of your product (spam sites) and directing your customers to use an extension to fix it is awful.

What faith I once had in Google being a company that puts users first is long gone.

<comment><USER30> Google has been shutting down features left, right and centre. I'm left wondering: what useful thing has google done since gmail and ads?

<comment><USER31> From the top of my head: V8, Golang, AngularJS, Closure Tools, Search by Image¹, Maps + Street View, Android, Now, Goggles, Fiber², Public DNS, GWT.

¹ not original, but works better than Tineye, in my opinion

² granted, only for a limited number of people

<comment><USER32> I'm sorry. You can combine all of them and they are still not as useful Google Reader & Blocked Sites. #sarcasm.

</comment></comment></comment></comment><comment><USER33> For god's sake. I literally just started using it for W3Schools about two months ago. It costs google practically nothing to do that, and now they suggest adding another extension to chew out yet more of my memory.

Plus it looks like they aren't going to adhere to the implications of having a number of users blocking a site. _cough_ w3schools.

<comment><USER34> I just noticed w3schools appearing again in my search results.. well this is the cause.

</comment></comment><comment><USER35> Note that you can continue to use the Chrome extension to block sites, which I believe we rolled out before this feature. Get it at [https://chrome.google.com/webstore/detail/personal- blocklist...](https://chrome.google.com/webstore/detail/personal-blocklist-by- goo/nolijncfnkgaikbjbdaogikpmpbdcdef)

And here's the blog post we did about the Chrome extension: [http://googleblog.blogspot.com/2011/02/new-chrome- extension-...](http://googleblog.blogspot.com/2011/02/new-chrome-extension- block-sites-from.html)

<comment><USER36> Interestingly enough this means you have to install software on your own computer to get better search results from a company that tries to deliver a hosted ("cloud") service. Seems backwards to me.

<comment><USER37> Well, I'm with Matt on this one. When blocklist rolled out people were stressing about having their blocked selections stored in the cloud, blocking rings to kill competing sites and so on. I think it makes sense to build that functionality in at the client end.

</comment></comment></comment><comment><USER38> I don't understand why this was discontinued. Surely this data would be a gold mine in improving the quality of search results, which is core to what Google does.

<comment><USER39> A blacklist that can be added to anonymously and unaccountably is not something you want affecting search results.

<comment><USER38> Sure it is, obviously you don't take any small amount of blocks as a signal. By getting a significant amount though and looking at each persons block list to normalize there blocks I think it would be useful.

<comment><USER40> > Sure it is, obviously you don't take any small amount of blocks as a signal.

You do realize spammers are extremely good generating large amounts of things, right?

> By getting a significant amount though and looking at each persons block > list to normalize there blocks I think it would be useful.

Spammers are also very good (though not great) at adding innocuous data alongside their spam to look like real users.

You don't realize it, but your solution has just exploded in complexity.

<comment><USER38> The same thing is true of backlinks. Sure there is a point in which it may not be worth the trouble, not questioning that.

</comment></comment></comment></comment></comment><comment><USER41> This feature didn't work at the best of times, and became so unreliable...

I also don't believe that the blocked sites was linked to my Google account, because I had blocked sooo many different pages on W3Schools that I just abandoned using the blocked sites feature altogether.

</comment><comment><USER42> I understand this from a technical perspective, but I always thought this feature had the potential to allow Google to gather better qualitative metrics about websites. For instance, if a huge chunk of people who are searching for web-related questions (end up on SO or MDN or something) and they all have ExpertSexChange and w3schools blocked, then perhaps those should be considered qualitatively worse and would therefore be ranked lower than the alternatives?

I guess not. I'm curious how they're determining quality in that case. Hey Bing, maybe you could pick this up and deliver quality results over faster results?

<comment><USER43> i'm sure that was the original intention, and the reason for the discontinuation is that nobody used it and the cost of maintaining the feature exceeded the value of the data they gathered from it. (or else everybody blocked the same few things in the first couple weeks the feature was available, and then they stopped learning anything from the feature)

<comment><USER42> Perhaps, but when useful features see lack of use, it's usually because it's a prohibitively difficult feature to use or very poorly presented.

Maybe if it was as simple as clicking a "never see results from this website again" it would've seen orders of magnitude more use and been far more useful. Perhaps an upvote/downvote system? Seems like these are relatively tiny time investments by a couple of engineers and would serve to massively increase the quality of results. Not sure why throwing useful features away is a better decision.

</comment></comment></comment><comment><USER44> A very good thing is the minus sign in google search. It allows you to exclude keywords and sites. They should expand that. My searchbar gets very crowded at times.

</comment><comment><USER45> I'm curious how all this "wood putting" is affecting staff attrition/layoffs.

If had invested my work into one of the major cut projects, I'd be fuming as an employee right now.

Also, it's interesting how many of the cut services seem to be around working, but slowly decaying and abandoned projects. It says something about google's ability to keep working on and developing products...especially since most of their products are essentially public betas.

</comment><comment><USER46> I wonder when will Google discontinue Gmail and offer to download all mail in a file.

</comment><comment><USER47> I don't remember using this feature much, but when I downloaded my block list this is what I found:

      www.teachexcel.com
      craftkeys.com
      softwaretopic.informer.com
      www.telerik.com
      eggheadcafe.com
      www.kaboodle.com
      bigresource.com

Damn those aggregator sites are annoying.

<comment><USER48> Why Telerik?

<comment><USER49> Every time I've gone there for ASP.NET advice it starts talking about Telerik controls, not the basic controls found in .NET.

</comment></comment></comment><comment><USER50> So they'll tailor search results for you personally based on what they think you'll want (or, eventually on what they want you to want), but they won't let you declare what you don't want?

</comment><comment><USER51> Personal Blocklist(by me) <http://crossrider.com/download/29789> > here an extension that works with firefox and google chrome (and maybe with some version of ie) > currently only block w3schools and expert-exchange :-) > will be extendable soon

it is not on the browser marktplaces right now, so you kind of got to install it manually.

</comment><comment><USER52> You can remove up to the top ones million sites with MillionShort: <http://millionshort.com/about.html> and you can specify individual sites to remove via settings: <http://millionshort.com/settings.php>

</comment><comment><USER53> This really sucks. As said above, it wasn't working anyway. Too bad it happened. I wonder if Google could've gained more knowledge about the common "undesired" results and use it to improve the search.

</comment><comment><USER54> Was that feature really that indispensable? I can usually get away by refining my search query, and more often that not, using the minus sign solves the problem.

</comment><comment><USER55> Makes sense to me.

I'd rather have my browser know what results I don't want, than Google.

However it is Google that provides me a browser (for free) bundled with a sync feature.

Anyway, goodbye W3Schools! :)

</comment><comment><USER56> Why is this even news? This was announced long time ago and I thought it was fairly evident. Use personal blocklist, instead.

</comment><comment><USER57> I came for the horror comments about experts-exchange.com and was not disappointed. At least two of you have mentioned it!

</comment><comment><USER58> No solutions for people not using Chrome?

<comment><USER59> I found this greasemonkey script and it seems to do the trick.

<http://userscripts.org/scripts/show/95205>

</comment></comment><comment><USER60> I know it fucking is! Which is why I am seeing Experts Exchange (a tall claim), ahead of Stackoverflow!

</comment><comment><USER61> As many others, I used this mainly to block w3schools from my searches. Disappointing to see it go.

</comment><comment><USER62> What disturbs me is how it's okay for Google to allow this "for Chrome users only" but it's a $700m fine for Microsoft for bundling Internet Explorer into the OS. Is Microsoft really more of a monopoly than Google? Of course not. It's ridiculous that MSFT gets fined such high amounts but no one questions Google's ethics or says, "Hey, wait a minute..."

<comment><USER31> Comparisons to Microsoft aside, it's not true that no one questions Google. The EU antitrust authorities have been examining them for two years now, they just haven't reached a conclusion yet: [http://www.reuters.com/article/2013/02/22/eu-google- idUSL6N0...](http://www.reuters.com/article/2013/02/22/eu-google- idUSL6N0BM4JI20130222)

<comment><USER62> Sorry - I misspoke. I meant "no one questions Google in this thread".

</comment></comment></comment><comment><USER63> I wonder how long it takes till someone comes up with "Blockedsitesly" ^^

</comment><comment><USER64> My blocked sites list only had one entry: experts-exchange.com</comment>