Things I hate about Rust - <AUTHOR> https://blog.yossarian.net/2020/05/20/Things-I-hate-about-rust <comment><USER2> > No current way to get the user's home directory. std::env::home_dir() is > explicitly marked as deprecated, and the documentation encourages users to > rely on the dirs crate (which is currently archived on GitHub).

Yeah, this is a bit of a farce. On the one hand, it seems fair to me to not have this in the standard library - it's not something that needs special cooperation with the compiler or runtime, it's not something universal (what would it do on an embedded microcontroller?), and it doesn't matter if different crates use different implementations. On the other hand, deprecating a standard library function in favour of a crate owned by a random user seems like an unforced error.

There's discussion here:

[https://www.reddit.com/r/rust/comments/ga7f56/why_dirs_and_d...](https://www.reddit.com/r/rust/comments/ga7f56/why_dirs_and_directories_repositories_have_been/)

Including the fact that there is an actively maintained alternative:

[https://github.com/brson/home](https://github.com/brson/home)

And a clue to why those repos are archived:

> I was wondering the same thing and contacted the author. He said that some > people had "lost their shit" over some of the things he mentioned about rust > and that to help them calm down, they will be archived until 2022.

!

<comment><USER3> > it's not something that needs special cooperation with the compiler or > runtime, it's not something universal (what would it do on an embedded > microcontroller?)

It's filesystem access, like the open file and read file functionality, so it needs some runtime support, and all filesystem access would fail on embedded microcontrollers, so I'm not seeing why it shouldn't be in the standard library.

<comment><USER4> Plenty of μC's have filesystems, probably the majority nowadays. They aren't necessarily running an operating system with a concept of users though. Besides, in C the file commands can be used to do non-file IO, so those functions still have a use even without a FS.

<comment><USER5> >probably the majority nowadays

I'd dispute that on the grounds that a microcontroller with a filesytem is likely doing something complicated enough that it lives on a board with at least one other microcontroller that doesn't.

I'll even go as far to say it's more likely that the majority of microcontrollers don't write to mutable storage other than RAM (if they have it at all) once they leave the factory.

</comment></comment></comment></comment><comment><USER6> If you think Rust strings are bad, you're obviously never developed on Windows.

From my failing memory, MBCStr, CComBStr, BStr, CString, XLString, and then all the unicode versions. Then you're developing in C++, so you also have std::string and std::wstring, oh and u16string, and u32string. Plus char _, and wchar_.

<comment><AUTHOR> Author here: I've spent about half a decade writing Win32 applications, including things deep in NTFS.

I agree completely that _everything_ about string typing on Windows is worse, especially once you stray off of the happy path. But the post isn't intended to equivocate against a ecosystem with 40 years of legacy APIs in it; it's to nitpick a _new_ ecosystem that I otherwise love ;)

<comment><USER7> I don't see an alternative to interfacing with that though. If we were to just use UTF-8 strings for everything then there would be files we couldn't handle in various OSs for example. So while it's a bit unwiedly to use filepath.to_lossy_str() etc. I prefer it to a leaky abstraction that hides necessary complexity.

<comment><USER8> It wouldn't be an issue if OSes forbade non-UTF-8 paths...

It's the unfortunate case that we have OS environments that are usually, but not always, UTF-8, and there's no clear, reliable indication of whether or not UTF-8 is to be expected.

</comment></comment></comment></comment><comment><USER9> For getting a users homedir I fall back to POSIX[0] (which windows follows in this instance fwiw).

There are some things that I'm bitten by as a rust newbie though; strings are definitely one of those, since it's more difficult to reason about strings as they're heap allocated, where as most "normal" types are not, thus to use Strings you have to learn the borrow checker..

Another issue I have is crate versions, and compiling and including _multiple versions_ of the same crate, because that crate is also a dependency on one of the crates I'm using.

Yet, another is crates that only support the nightly compiler, which you're not supposed to use for production, there needs to be some way of delineating the "stable" version of a crate with the "potential future" version of a crate.

Even if you stick to a version and the nightly compiler supercedes then you end up with the same error:

\</comment><comment>8<\</comment><comment>

        Caused by:
          process didn't exit successfully: `/Users/dijit/projects/rust/Rocket/target/debug/build/rocket_codegen-6474f79f6391da32/build-script-build` (exit code: 101)
        --- stderr
        Error: Rocket (codegen) requires a 'dev' or 'nightly' version of rustc.
        Installed version: 1.43.1 (2020-05-04)
        Minimum required:  1.33.0-nightly (2019-01-13)

\</comment><comment>>8</comment><comment>

[0]: in POSIX the OS _must_ set $HOME: [https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd...](https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html)

<comment><USER10> I'm not sure about home dir but a thing I've needed is a standard place to store app stuff. On Windows it's a mess. There's AppData/Local, AppData/LocalLow, AppData/Remote and many apps store a ton of stuff in their app folder in c:\programs etc... On Mac I guess it's Library/Application Data but there's a bunch of other folders under Library. On Linux I read somewhere it's .config but there was no .config on my Linux installs and it seems strange to me that apps should be required to make this folder vs the OS and that the OS doesn't tell me where it is it's just convention. But in any case, I think I wish some standard library handled this.

<comment><USER9> Yes, I understand, and I feel your plight, as it stands this is what I would use:

$APPDATA on windows[0] or $LOCALAPPDATA

$XDG_CONFIG_HOME on linux[1], which is where you're getting the ~/.config from.

For MacOS, it's a mess[2], you should probably use ~/Library/Application Support/script_name/ for most things though.

[0]: [https://ss64.com/nt/syntax-variables.html](https://ss64.com/nt/syntax- variables.html)

[1]: [https://wiki.archlinux.org/index.php/XDG_Base_Directory](https://wiki.archlinux.org/index.php/XDG_Base_Directory)

[2]: [https://developer.apple.com/library/archive/documentation/Fi...](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1)

<comment><USER8> > $XDG_CONFIG_HOME on linux[1], which is where you're getting the ~/.config > from.

XDG_CONFIG_HOME is ~/.config if not otherwise specified.

</comment></comment></comment></comment><comment> kris-s My biggest gripe with Rust is that is doesn't spark joy. I intellectually agree with a lot of its goals but every time I write some Rust I just find it dreary. Maybe it's the ugly syntax, maybe it's the "code feel" of interacting with a grumpy compiler.

That said I know a lot of folks really dig it and think it's a breath of fresh air; more power to em'.

<comment><USER9> That's a shame, I find Rust (and, ruby) spark incredible amounts joy to code in.

But I find that Go does not spark joy for me. ('.Dial'?!, first character case denotes public/private D:).

I guess that it is very subjective.

<comment><USER11> '.Dial' ?? What else would you expect instead of Dial ? If you get demoralized from an imperfect function name you are in the wrong domain of activity.

<comment><USER9> .connect() or connection.new() like everything else.

Python: [https://wiki.python.org/moin/TcpCommunication#CA-b22bc303d6d...](https://wiki.python.org/moin/TcpCommunication#CA-b22bc303d6d0b4c7af1a18623aacd1d0900b6ff3_12)

Ruby: [https://ruby- doc.org/stdlib-2.5.1/libdoc/socket/rdoc/TCPSock...](https://ruby- doc.org/stdlib-2.5.1/libdoc/socket/rdoc/TCPSocket.html)

Rust: [https://doc.rust- lang.org/std/net/struct.TcpStream.html](https://doc.rust- lang.org/std/net/struct.TcpStream.html)

Julia: [https://docs.julialang.org/en/v1/manual/networking-and- strea...](https://docs.julialang.org/en/v1/manual/networking-and- streams/#A-simple-TCP-example-1)

C++: [https://github.com/KMakowsky/Socket.cpp/blob/master/Socket.c...](https://github.com/KMakowsky/Socket.cpp/blob/master/Socket.cpp#L73)

Win32 C: [https://docs.microsoft.com/en- us/windows/win32/api/Winsock2/...](https://docs.microsoft.com/en- us/windows/win32/api/Winsock2/nf-winsock2-connect)

Linux C: [http://man7.org/linux/man- pages/man2/connect.2.html](http://man7.org/linux/man- pages/man2/connect.2.html)

Swift: [https://github.com/apple/swift- nio/blob/master/Sources/NIOEc...](https://github.com/apple/swift- nio/blob/master/Sources/NIOEchoClient/main.swift#L96)

Java: [https://docs.oracle.com/javase/7/docs/api/java/net/Socket.ht...](https://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#connect\(java.net.SocketAddress\))

Javascript: [https://gist.github.com/tedmiston/5935757#file-nodejs-tcp- ex...](https://gist.github.com/tedmiston/5935757#file-nodejs-tcp-example- js-L37)

Anyway, it's not about being demoralised, it just doesn't "spark joy". :)

<comment><USER12> Go follows the Plan9 system call name instead of the UNIX one. Dial is much more powerful than the UNIX dance of "getaddrinfo"+struct sockaddr init+connect(2).

It might not seem much (and higher level languages usually abstract away the craziness that UNIX sockets are in C), but that's what the OS still gives you in 2020...

<comment><USER13> Plan 9's dial() interface is implemented in a user land library. In terms of the interfaces provided by the kernel, connecting a socket is _anything_ but simple in Plan 9. See [https://9p.io/sources/plan9/sys/src/libc/9sys/dial.c](https://9p.io/sources/plan9/sys/src/libc/9sys/dial.c)

The reason no standard interface has replaced getaddrinfo + socket + connect is probably because it's just barely simple enough for common usage in C, and C was never the language you turned to when you wanted to write something short and sweet--that's why Unix environments have always hosted a myriad of other languages. If initializing a network connection were as complex as in Plan 9, doubtless Unix _would_ have provided a more succinct libc interface for the common case

The BSD Sockets API is also close to the simplest possible interface for supporting all the various address and socket option combinations that are possible. (The kernel provides mechanism, not policy.) So even if POSIX, Linux, or whatever included a better standard interface for initializing a connection, it would have to be in _addition_ to the BSD Sockets API (or equivalent).

<comment><USER14> BSD Sockets are infamous for being significant issue in using _anything_ other than IPv4 (getaddrinfo is copied over from XTI, aka Streams-related "evil" API).

They are literally a low-level API that happened to be part of IPv4-only stack because DoD had short deadline to get IPv4 ported to VAX and other new Unix machines.

And OS _should_ provide a policy when it comes to networking, otherwise you end up with never ending story of working _around_ other's software to implement them.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> The `dirs` crate has been recently forked and revived - the new home is here: [https://github.com/xdg-rs/dirs](https://github.com/xdg-rs/dirs) (and the crate is named `dirs-next`).

Given the relatively sparse nature of the standard library, and the cost of making mistakes (std::sync::mpsc, anyone?!) I can see why this is omitted. IMO it's a fair criticism that pulling in lots of crates is less than ideal, though.

<comment><USER16> > std::sync::mpsc, anyone?!

Can anyone expand on this? I'm not well versed in Rust lore and have just used that module in a recent learning project.

<comment><USER17> Found this post [https://stjepang.github.io/2019/03/02/new- channels.html](https://stjepang.github.io/2019/03/02/new-channels.html)

with a link to a comment on GitHub: [https://github.com/rust- lang/rust/pull/42397#issuecomment-31...](https://github.com/rust- lang/rust/pull/42397#issuecomment-315867774)

<comment><USER15> Yes - sorry, this is the comment I was referring to. I'm not aware of _bugs_ in `std::sync::mpsc`, more concerns around things which could have been done better which are now not possible to retrofit because of the guarantees of the standard library with respect to backwards compatibility.

</comment></comment></comment></comment><comment><USER18> Perhaps Rust should make clearer that `String` is a string buffer and not just a string type. Other than that I think Rust does need different string types for different situations.

As to the standard library, I've actually started to think it's too big. I know this may sound like heresy for someone coming from a language with a big standard library. However, I think it should do whatever needs compiler support and have some traits for easier interop and that's about it. EDIT: Perhaps also some functions to help handle the more fiddly UB risks.

Rust has a great, easy to use ecosystem. More needs to be done to point out the trusted and well tested crates and to point people in that direction. The standard library itself is much harder to contribute to and has stability guarantees which can potentially make mistakes costly in the long term.

<comment><USER2> There's definitely a theory that the pairs of view and buffer (or borrowing and owning) types should have been more consistently named. I think steveklabnik usually manifests in these threads to express it. But it's something like:

str is to String

as &[] is to Vec

as Path is to PathBuf

... and the names should reflect that.

<comment><USER19> Yep, you nailed it. I wouldn't change Vec though. I would make the string types more consistent with the path types. The reason is that slices are more general than just vectors, whereas str/String and Path/PathBuf are _virtually_ always only used together.

<comment><USER2> Fair enough. Although i'd rename Vec to List, because variable-length sequences are not vectors, and there's no need to propagate that mistake any further!

<comment><USER19> The problem is, some people think List means some form of linked list, not what a vector is.

Names are hard.

</comment></comment></comment></comment></comment><comment><USER20> Skipped over my personal biggest annoyance, the inability to abstract over mutability (example: [https://www.reddit.com/r/rust/comments/2a721y/](https://www.reddit.com/r/rust/comments/2a721y/))

<comment><USER21> Argh, I ran into this last week. I ended up just copying the code and nudging. I wonder if a macro could be used as a workaround?

<comment><USER22> Funny that's the exact same issue that C++ const cast 'solve', of course D's inout solution is much more elegant.

</comment></comment></comment><comment> http-teapot I have the same problem with strings as well. I think I understand the difference between String and &str but I wish it'd automatically convert String into &str when a function expects it.

Example: `std::env::var("SOME_PARAM").unwrap_or_else(|_| "localhost".to_string())`

It just seems odd to me, something tells me there is a better way to do this but I couldn't find it.

<comment><AUTHOR> > I have the same problem with strings as well. I think I understand the > difference between String and &str but I wish it'd automatically convert > String into &str when a function expects it.

Yep! My understanding is that `AsRef<str>` is the right way to do this automatic conversion but I learned that by reading library code, not from the standard documentation. It'd be awfully nice if the compiler could do those sorts of conversions automatically; injecting `AsRef` everywhere adds a lot of visual clutter.

<comment><USER23> > injecting `AsRef` everywhere adds a lot of visual clutter

I agree!

`fn foo<T: AsRef<str>>(s: T)`

This is so difficult to read, one has to jump back and forth with eyes to make any sense of these. Why couldn't there be easier syntax for "AsReffing"? E.g.

`fn foo(s: @str)`

I invented @-sign there.

<comment><USER19> Syntax like @T was actually a type in ancient Rust. People really, really hated having even more sigils in the language, so we ended up removing them. There was also ~T.

<comment><USER8> IIRC, one of the sigils was for reference counting, and there was to be another one for garbage-collected types?

(I'm recalling the lunch conversations from when I sat in the room with all the Rust interns).

<comment><USER19> @T was supposed to be a GC'd type, but ended up being a refcounted type. It was removed before it actually turned into a GC'd type.

~T was Box<T>.

However, one issue here was that they didn't compose in the same way as types today; ~str existed, for example, but was not the exact same as String in terms of memory layout. Conceptually they're the same thing though.

</comment></comment></comment></comment></comment></comment><comment><USER24> The strings actually make sense. The difference between String and &str is same as between Vecs and slices. Don't use OsStr unless you have to.

<comment><USER25> The problem is naming though. Calling something a "slice" connotes the existence of a whole somewhere from which the slice was taken. The string types just call themselves same thing with some funny syntax and oddly inconsistent capitalization and abbreviation conventions.

This non-behavioral stuff matters. Almost literally no one who comes to rust understands the string types with any intuition initially. And strings are really important!

Much the same thing can be said about the evolution of other areas of rust syntax (macros and attributes come immediately to mind). The final result is a collection of syntactic soup with (mostly) well-defined and internally consistent _behavior_ , but with a syntactic expression that bears the archaeological scars of its evolution.

<comment><USER24> > The problem is naming though. Calling something a "slice" connotes the > existence of a whole somewhere from which the slice was taken. The string > types just call themselves same thing with some funny syntax and oddly > inconsistent capitalization and abbreviation conventions.

That is not the case.

</comment></comment></comment><comment><USER26> A few of my own:

Declaring/initializing a medium sized array of structs, is simply too verbose if you have meaningful structure names. What is a few lines in C explodes into pages in rust.

Type inference on declarations but, not function parameters, WAT!

The scoped constructor syntax is designed to miss the concept of RAII.

Array's by themselves are nearly useless, might have just made Vec<> the default array type.

Variables end up being &mut even when its not necessary because the compiler forces the attribute to be carried along in a number of cases when its not rightfully needed.

As I've complained about before, many of the 3rd party cargo libraries need additional traits before they can be mixed with threads/mutexes unless your willing to use unsafe.

Then there are all the bad style choices, starting with the javascript like nested calling (aka obj1.call().call2().call3().call4().call5();) chains spread over whole pages of code. Mismatch braces (yah I know this one is everywhere in C/javascript/java too, doesn't make it right). Trait declarations that are scattered everywhere rather than being centralized like a C++ class.

<comment><USER27> > Type inference on declarations but, not function parameters, WAT!

This is a hard restriction in place on purpose. The compiler could perform inference for the input and output types as part of the language but that means that the actual low level signature of your function could change by changing either the implementation or the callers. This is a compromise we must have to avoid surprises in real programs that have public APIs. On the flip side the _compiler_ doesn't have this restriction for inferring the return type. If you write a function signature `fn foo() -> _` with a body that can resolve to an unambiguous type, the compiler will give you a structured suggestion for the correct type. This way you get the benefit of inference when developing _and_ the benefit of type safety and unambiguous documentation of your code at the cost of mild inconvenience.

> Array's by themselves are nearly useless, might have just made Vec<> the > default array type.

I'm not sure what the actionable recommendation is here. Is it to have made [] the syntax for Vec? If so, that would have made Vec special from the language's point of view, when it doesn't need to. Today you can reimplement all of Vec in your own Rust code, but you can't for arrays, because the compiler and language need specific memory layout information about them.

> Mismatch braces

Could you expand? I'm intrigued what you mean by this.

> Trait declarations that are scattered everywhere rather than being > centralized like a C++ class.

This enables very flexible design and composition of behavior. It feels very weird when coming from an OOP background, but I've come to prefer it after a while.

</comment></comment><comment><USER28> _> No way to invoke a command through a system shell. Yes, I know that system(3) is bad._

I think a crate that offers more shell-like convenience functions/macros for scripting would be more powerful than just adding a system()-equivalent to the standard library.

</comment><comment><USER29> I quite like the way Rust handles strings. Better than Haskell.

<comment><USER30> I think it's pretty bad in both languages. In Haskell it's trivial to understand the difference between a ByteString and Text. The names give it all away. You do need to know the difference between lazy and strict values, but that's universal to the language and not hard to understand. I'd say that strings in Haskell are more annoying than hard to understand. In Rust, even figuring out why some of the string types exist in the first place and what they mean is hard, and you still have the interconversion problem, which now is not only annoying but also difficult to understand.

<comment><USER31> Haskell implementing strings as _lists_ of characters is a problem. Basically, you can't use them for anything performant.

A proper string library should be a Functor, naturally, but it should also be much more like a rope and much less like a list under the covers and in its API.

<comment><USER30> I agree, but that's why you use Text and ByteString. Annoying? Yes. Hard to understand? Not at all. Rust strings to me are both annoying _and_ hard to understand and explain.

</comment></comment></comment></comment><comment><USER32> As a Rust beginner, the point about strings really resonated with me.

<comment><USER33> Over time I found that I appreciated it more and more. There's a lot of weird and wonderful edge cases and it's a joy to see them encoded in the type system. You don't have to resort to stackoverflow questions like this: [https://stackoverflow.com/questions/2050973/what-encoding- ar...](https://stackoverflow.com/questions/2050973/what-encoding-are- filenames-in-ntfs-stored-as/2051018#2051018)

</comment></comment><comment><USER34> Not being able to execute in the current shell has been a bit of a pain...

Want to write a environment variable that lasts the lifetime of the current shell session? No way to do it.

<comment><USER35> Is that a Rust problem? How would you normally do it that fails in Rust?

</comment></comment><comment><USER36> That string situation in Rust sounds like a lot of cognitive load. I wonder why can a language like Nim (which competes with Rust) have such wonderful dev ux where you can just go `string` and Rust has this thing?

<comment><USER37> Just a guess but probably because Nim uses a garbage collector and probably doesn't make the same memory safety guarantees that Rust does.

<comment><USER38> The garbage collector is optional and Nim is memory safe.

Just like Rust, you can unsafe structures when using libraries in C/C++.

</comment></comment></comment><comment><USER39> Reading this confirms that I was right to pick Go for a couple things.

My very strong opinion is that the language should impose _as little cognitive load as possible_. Rust seems like it makes you think a lot about Rust, which means you are not thinking about the problem you are trying to solve. Brain cycles are a finite resource.

I don't want to diss Rust too much though. I see it as a potential future replacement for C/C++ for bare metal stuff where you really do want to hand craft the code for maximal performance or directly interface with hardware. That is a different niche than building higher level stuff, and I don't think anyone has managed to make a language that is good for both (yet?).

<comment><USER35> Can't agree. Rust's goal, if you can call it that, is to make you think about things you should be thinking about anyway.

Coming from C, you should be thinking about lifetimes and mutability and sharing. If you dont, your program may work but be buggy. Rust forces you to think about that.

Go does the same thing in different ways at different costs. It trades memory/performance so that you don't have to worry about allocations and simply doesnt use standard shared mutability patterns (not exactly, but channels take up most of the same space).

<comment><USER40> I don't understand why the parent post of yours is getting this much downvotes. What's wrong with using a GC'ed language when performance requirements are permissive?

<comment><USER35> That's not precisely their statement even if it is their intention. I don't think anyone could argue that statement (though some may deny your axiom of lax performance requirements).

I think people are taking issue with the claims that _Rust_ is imposing the cognitive burden. As I said, these burdens already exist, languages just weren't forcing people to deal with them.</comment></comment></comment></comment>


ReMarkable MicroSD - <AUTHOR> http://www.davisr.me/projects/remarkable-microsd/ <comment><USER2> Wow! That's like two levels up from mine. I would like that my remarkable has a as card too, but this seems too risky for me.</comment>


Why it must be your most interesting idea - <AUTHOR> https://www.getsdone.io/blog

<comment><USER2> I get big red page in Chrome saying your SSL certificate does not match the domain. You need to fix that first. Also another big red message on you website explaining your product. Please use a different colour

<comment><AUTHOR> ok, this is fixed, please have a look.

<comment><USER2> Nope, still get the same Google warning and your red background

<comment><AUTHOR> sorry for the late response, thought this thread was dead. i'm using various browsers safari ios, safari mac os x, chrome, etc, not seeing this problem after my changes.

i imagine this maybe a problem with your browser cache? basically i have re- routed all http requests to https and the certificate is valid (purchased from rapidssl). what browser are you using?</comment></comment></comment></comment>


Windows 10, Privacy, and the Hole in the Sky - <AUTHOR>

The privacy concerns. The letter from the Mozilla guy. I'm not even saying that they aren't valid. The vitriol and high-horse moralizing. How is that productive HN style discourse? None of it's constructive. How can we talk about these issues in a way that doesn't blow them out of proportion and actually exchange some information? <comment><USER2> I'm not sure how this is blowing them out of proportion. The 'Express' configuration that nearly every user will run with sends virtually everything you do to Microsoft. Please explain how that is not a serious privacy concern.

<comment><AUTHOR> That's not really accurate. Maybe we can reach out to someone at MS and they can explain exactly what is being sent. It certainly isn't virtually everything that you do...it's something, it's not accurate to say its everything.

MS people frequent this site. Maybe one of them could get some detail on the subject?

<comment><USER2> It is keystrokes, app you use, browsing and search history, speech, encryption keys.. That's a concerning amount of information.

This is where I __strongly __prefer the Apple way of signing in with a normal account and -- if you choose -- linking it to an iCloud account. This is very different from the Windows style where MS accounts take over your local login.

<comment><AUTHOR> I just don't think that's an accurate picture. They aren't recording your voice and storing it somewhere. Browsing and search history are collected by other platforms for predictive browse ahead and autocomplete, and it's a useful feature. App usage is collected for diagnostic purposes.

You don't have to use a MS account. You can use a local account. 10 is different from windows 8 in that regard. You can take Cortana off the taskbar. Use a different browser in incognito mode all the time. Store your encryption keys in a TPM, smartcard, or Active Directory. There are actually lots of options. You have to actually look into it though.

<comment><USER2> Right. The problem is that 99% of users are going to be using these defaults-- not that you or I can't figure out how to disable it.

<comment><AUTHOR> So, a second ago it was that you can't use a local account...but you can, so now it's..."The defaults are bad and people are dumb."

Literally all of the people who install it or buy a PC with it installed have the choice of making that decision or purchase.

And you're right, they won't change the defaults and that's not a travesty of some kind. It actually really doesn't matter to most people. Not because they don't understand it. They do, and they want to use it for one reason or another. People in our technical circles overestimate the importance of this stuff by some fairly crazy amounts.</comment></comment></comment></comment></comment></comment>


How Queen and Pink Floyd were judged before they were famous - bauta-steen http://www.bbc.com/culture/gallery/20171122-how-queen-and-pink-floyd-were-judged-before-they-were-famous <comment><AUTHOR> Interesting information, but I must say I _hated_ the delivery. A faux slideshow format with animated graphics in between very busy images with overlaid text.

Oh how I miss the good old simple web page with a block text on a white background, an image, a block of text, an image... etc. as you scroll down the page.

<comment><USER2> Personally I liked it. Looking at those authentic, old, typewritten documents added a certain charm, and brought me back in time. I wish the "animated" segments were longer, and included audio, though. I was even looking for an "unmute" control on the first one.

<comment><USER3> I also thought the delivery was pretty good. But found the image quality too low to easily read the notes in the background (and would also have liked audio for the videos).

</comment></comment></comment><comment><USER4> Fascinating that The Who were considered an R&B group early in their career, then transitioned to hard rock.

As for Led Zeppelin, I'm amazed that they still had to pass an audition _after_ they released the eponymous Led Zeppelin record (the one with the Hindenberg exploding on the cover). That's got to be one of the best albums of the 1960s, if not in the whole of rock. Looks like the jury was out at that early stage of things, though.

<comment><USER5> Same with The Rolling Stones and quite a few other early British rock bands. US R&B was a big thing in the early scene.

</comment></comment><comment><USER6> It's interesting to read because it's easy to think of the BBC is a staid, state organization whereas this demonstrates how it actively tries to fulfill its public service.

A while ago I went to an exhibition of the work of Oliver Postgate[1] who produced a number of very well known and delightful children's programmes for the BBC in the 1950s to 1980s.

There was a wonderful letter written by someone at the BBC about Postgate: [https://twitter.com/jgrahamc/status/782295197078224896](https://twitter.com/jgrahamc/status/782295197078224896)

"I feel it is our loss that we have so far been unable to find employment for this odd but valuable person".

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

<comment><USER7> >very well known and delightful children's programmes for the BBC in the 1950s to 1980s.

That's an understatement! The Clangers and Bagpuss are up there with the Daleks for recognisability in Britain.

<comment><USER6> Don't forget Noggin the Nog.

</comment></comment></comment><comment><USER8> _" Elton John – 1968...Pretentious material, self-written. Sung in an extremely dull fashion without any feeling and precious little musical ability. Thin piercing voice with no emotional appeal."_

Heh. All that lack of ability and emotion sure held him back.

<comment><USER9> Just imagine what he could have been if he had ability and emotion ;)

</comment></comment><comment><USER10> Top gear was originally a music program? That's unexpected.</comment>


Ask HN: Where are the 750k Bitcoins lost by Mt. Gox? - <AUTHOR> <comment><USER3> In November of 2011 Mt. Gox demonstrated control of 500k BTC.

I followed the 500,000 BTC for a bit beginning at [https://blockchain.info/tx/b269bf1b82dae8a61f7f91dbf7a9d807e...](https://blockchain.info/tx/b269bf1b82dae8a61f7f91dbf7a9d807e30963c1ae00ddd95a8faebea6d0a007).

The coins move around and small amounts are sent away, but the majority ends up back in Mt. Gox's main (hot) wallet. This repeats a few times until the majority is paid back to the main Mt.Gox address.

Here is the transaction where it starts to get interesting:

[https://blockchain.info/tx/478ea915aa3a2e54503c43e1c5659722b...](https://blockchain.info/tx/478ea915aa3a2e54503c43e1c5659722b42a784412423a05394c83a44affb805)

What's left of the 500,000 (429.9k) is split into roughly half and sent to 2 new address. And then each of those address splits the coins in half and sends to two new address.

The end result is that the 429k was split again and again until the funds are split into many addresses, each of which now contain less than 1,000 BTC each. I stopped following the transactions there.

Why take 429k and split it into many addresses each containing less than 1,000 BTC each?

I'd like to see someone trace all of these coins and see if they end up coming together somewhere or show a pattern.

<comment><USER4> I'm a bit new to bitcoins, but is it technically possible for the bitcoins community as a whole to make a blacklist of bitcoins addresses and "ban" the stolen bitcoins ? Such blacklist would daunt robbers and enforce public trust in bitcoins.

<comment><USER5> Well, the supply of BTC is finite, so simply excluding stolen BTC's has some additional problems. May be better than not addressing it, but while BTC provides a mechanism for following them through the transaction chain, it's not that simple to ID what addresses contain "stolen" BTC. What if the thieves are able to launder them through unwitting proxies? For example, steal a bunch of BTC, sell them on another exchange immediately, and now, how do you blacklist those "stolen" bitcoins without screwing over an innocent bystander?

<comment><USER6> Because transactions are recorded in a public blockchain, couldn't that be a big downside for anyone accepting bitcoin whether or not the coins appear on a blacklist/warning list. If a sending wallet address is associated with some contested activity (e.g. someone getting sued, or indited), I could imagine that those BTC could easily get swept up in the legal actions to unwind or resolve the activity.

This vs accepting cash which is fungible, and would need some other evidence associating the buyers money with the contested activity. At least the resolution activity there would likely be stopped at one level from receiving the cash, but with BTC, you happen to be able to track that one specific coin right through multiple layers of transactions. I can see lawyers tracking all the way out to the current holder of a given BTC.

edit: Upon a bit more side reading, I think the tracability of a given BTC is a bit overstated here.

<comment><USER5> That is assuming you can "blacklist" addresses before the transaction takes place. Or they could just create a new BTC address.

</comment></comment></comment></comment></comment><comment><USER7> I suspect that the bitcoins have been exchanged for something else and are back circulating around. The beauty of the heist is that any bitcoin in circulation invariably passes through transactions where the parties have a compelling interest in not being attached to the transaction.

After finding a stolen bitcoin, unravelling its history back to the Mt. Gox Heist is likely to meet a wall of resistence - e.g. if it passed through Silk Road the parties on both sides will be reluctant to come forward and provide information.

In terms of a tort, is it civil or criminal? Was the loss of the coins by Mt. Gox simply an unsatisfactory business transaction? Supposing there was a theft, how should the bitcoins be valued? By the amount of storage space they consume, by the cost of the resources required to create them? If by some market price, which one - some average at the time of their creation, at the time of their loss, at the time of their recovery, or at the time of the prosecution? Many of those values are zero.

Finally, how many of Mt. Gox's customers are going to come forward and claim ownership if such claims are accompanied by a risk of being asked "And how came you to acquire these bitcoins?"

Unlike fiat currency, no government has an interest in supporting the agreed upon fiction that bitcoins are not a fiction. Stealing cash is a crime because the government has an interest in cash being an asset.

The problem with cryptocurrency is the proportion of black and grey market interests it attracts. With bitcoin, they were there first and good citizens second. Separating good citizens from their money was always going to be an attractive option, probably more attractive than separating participants in the black and grey markets from theirs given the greater potential for more serious reprisals which might accompany theft.

It's been over since the first Bitcoin story on NPR.

</comment><comment><USER8> Some info here: [http://www.reddit.com/r/Bitcoin/comments/1z37zw/mt_gox_has_a...](http://www.reddit.com/r/Bitcoin/comments/1z37zw/mt_gox_has_at_least_200k_btc/)

"MtGox still has at least 200k BTC"

Here are the possibilities, as far as I can tell:

1) That information is inaccurate.

2) MtGox lost their private keys.

3) The private keys were kept in a bank vault, which was seized by a foreign entity like the US government at some earlier time.

4) MtGox stole the coins.

The management of MtGox knows which of these is correct, but they probably aren't going to say.

<comment><USER9> 5) they were stolen

<comment><USER10> Which is the same as 2) and 3).

<comment><USER11> No, could have been stolen through bugs in their software (e.g. transaction maleability), not directly from stealing the keys

</comment></comment></comment></comment><comment><USER12> With the possibility of getting down voted into oblivion.

The BTC lost/stolen are all available within blockchain/public ledger. Depending on who stole them, it would probably be distributed within multiple very smaller transaction.

It my be traceable, but likely unrecoverable, because this is a feature of Bitcoin. In other words authorities and forensic enthusiasts can find the BTC but they are most likely lost at the same time.

<comment><USER13> This is the issue. It can become a never-ending wild-goose chase. The thieves can continue to move the funds around until they're no longer tracked, or far enough ahead that from the trackers (assuming there's any enforcement or penalties or laws relating to accepting stolen Bitcoin - which there aren't currently) or just spend them if they're not being tracked or if there's no enforcement in place.

The thieves will move funds around at little cost in order to try to gain the value from the Bitcoin they stole.

The problem with Bitcoin is that because there's no fee associated with them, there's no money or resources being made available or directed towards policing and following of these thieves.

Edit: And it's not particularly fair to use the rest of society's resources to do this policing, when they're not contributing to the system - they're avoiding contributing, to a partially corrupt and currently inefficient system, yes - but it'd be better to fix these inefficiencies and deal with the corruption.

<comment><USER14> Wouldn't, in this high profile clustereff, somehow tracking down those bitcoins cause bitcoin in general more harm than good? Would it not highlight that one way or another, either by fault of bitcoin or human error, that like Tor it is not bulletproof in terms of anonymity and susceptibility to being taken back from someone, whether that someone is a good or bad guy?

<comment><USER13> Taken back? Finding a person is one thing - you need a lot of resources to track a person down - then trying to find where they may have hidden the keys needed to use the Bitcoin is another. People who have stolen millions of real dollars are still able to just hide the cash or money in off-shore accounts. Similar problems exist, though it doesn't start off anonymously. It's not really good or bad, it just is. We need to manage for best case scenario, and structure systems to provide best case scenarios. Controlled or rather fully- manageable ecosystems are the best, though they have the ability to be badly managed and through political lobbying, etc. cause a whole series of problems in a society.

</comment></comment></comment></comment><comment><USER15> Why doesn't Mt. Gox just publish the ID of the wallet(s) from which they were stolen?

1\. They weren't stolen - lost in cold storage harddisk failure for example

2\. Revealing it would show something extremely embarrassing - they only used a single wallet?

3\. They still have them - yay?

4\. They were stolen by Mt. Gox - <USER2>

<comment><USER16> MtGox may just have larger problems right now and can't get around to the actuarial work involved.

Though I agree a cold storage failure is still a good possibility, given the poor communication.

</comment></comment><comment><USER17> "The Lost BitCoins of Mt Gox" sounds like a good Scooby Doo episode. Or Hardy Boys?

<comment><USER18> _Velma yanks off mask._

 _Daphne gasps_

"Mr. Karpeles!"

Fred: "Mark Karpeles was the thief all along!"

Karpeles: "And I would have gotten away with it, too, if it hadn't been for you meddling kids!"

<comment><USER19> Velma didn't even say Jinkies yet :(

</comment></comment></comment><comment><USER20> Here s an idea..

Feds sized silk road and the Bitcoin wallets

If any was stored or transacted at MTGox this might be some of the amount of losses MTGOX is now showing but NOT ALL OF The lOSSeS obviously

<comment><USER21> Bingo. The Feds seized their cold wallet somehow.

Mark has said repeatedly that Mt. Gox is under investigation and that he can't talk about it. There's a supposed IRC log from two days ago where he let it slip that he's under a gag order, saying two days ago "le gouv US ne veut pas qu'on disclose" (the US gov. doesn't want us to say anything)[0]. And he's said in public that he can't discuss the matter since he's under investigation.

So my guess is that the feds have seized his cold wallet as part of the Silk Road investigation, or even as part of the case against Mt. Gox itself, which was probably in a safety deposit box. They've already seized 5 million USD last year from Gox, why wouldn't they go after the Bitcoins, too?

And yes, the seized Bitcoins would not equal the number owed, but my guess is that they're the majority of them, say 80%.

If that's the case, account holders would have to petition the USD to prove they're not drug dealers and or tax evaders to get their money back.

<comment><USER22> This is an unusually silly conspiracy theory.

I find it extremely unlikely that MtGox would falsely claim that they suffered a theft due to transaction malleability (a real point of possible error) if the actual issue was a US Government seizure. It just strikes me as utterly unbelievable that they would actively cover up (rather than simply failing to disclose) a government seizure.

It's far, far more likely that Karpales is either grossly incompetent or a thief than it is that he's making up complicated stories to cover up a government action.

<comment><USER23> You can't disclose if you are under a gag order. If Mark was running a fractional reserve because the coins were seized, and they got hit with the transaction mailability issue, that could set the stage for what we're seeing today.

I agree Occam's Razor applies here. That said, we still don't know a lot about what happened.

<comment><USER24> Would a gag order from a US court apply to a Frenchman in Japan?

<comment><USER25> In theory, or in reality? There could be explicit, implied, or even naively assumed 'underhanded compliance encouragement' going on.

I wouldn't put my money on explicit, but if it was, it wouldn't be the first time.

</comment></comment></comment></comment></comment></comment><comment><USER26> This is another possibility people are overlook, that perhaps they never had them. Perhaps they simply built up a liability of 800k bitcoins by trading on their own exchange and making some bad calls.

<comment><USER16> If I had to venture a guess, I'd bet that not even Mark Karpeles knows what happened to the money.

</comment></comment><comment><USER27> Whilst the numbers quoted in US dollar terms are quite staggering, I would be interested to know what the actual losses are based on the initial investment dollar amount.

I'm guessing many of these coins were mined or bought before the astronomical price rises.

Of course I understand that that is irrelevant to people who have perceived millions of USD, but interesting nevertheless.

<comment><USER28> This is an interesting point. This value is all speculative until the it's resolved by conversion to another currency. The entirety of my LTC holdings are from mining coins, trading out to USD before it dropped, then 'buying' in again. I ended up with around five hundred bucks worth, mostly due to just smart trading, costing me nothing.

The value has recently dropped, and I'm sad that I didn't cash out before, but I didn't actually lose anything. I'm still up the entire value of my portfolio, I'm just not up as much as I was before (and could have cashed out at).

I do feel bad for the people who bought in and then lost it all.

</comment></comment><comment><USER29> Any truth to the claims made on this website?

[http://www.doctrackr.com/blog/bid/376566/409-Million-in- Bitc...](http://www.doctrackr.com/blog/bid/376566/409-Million-in-Bitcoin- Stolen-Who-is-to-Blame?utm_source=hacker- news&utm_medium=social&utm_term=post&utm_content=ddos- attacks&utm_campaign=Blog-Post-2-28)

"The Pony botnet attack was an ambitious data collection program. TrustWave reported staggering data loss statistics from the event the following sensitive information was stolen.

1,580,000 website login credentials 320,000 email account credentials 41,000 FTP account credentials 3,000 Remote Desktop credentials 3,000 Secure Shell account credentials Pony's attack on the Bitcoin community took down the worlds largest Bitcoin exchange, and caused the price of Bitcoin to plummet. The attack reinforced security concerns over the currency. Can confidence in Bitcoin recover?"

</comment><comment><USER30> "In the blockchain".

Assuming they weren't lost because someone forgot a password, all of the BTC lost / stolen in transaction malleability _are_ traceable. Whether or not its feasible to check every transaction from Gox over the last few years and add up all the partial BTC is something I can't comment on.

<comment><USER31> there are top men working on this very thing.

</comment></comment><comment><USER32> Here's what I would do if I stole 750k Bitcoins.

1\. Split the wallet up into as many wallets as possible. Preferably by transferring them through a couple hundred compromised (but not emptied) accounts.

2\. Sell each individual wallet of say, 100-1000 BTC, on the black market. Make sure the transaction happens outside the transaction chain (i.e. either in real life or using other wallets with some kind of alternative trust system).

3\. Be prepared to lose 5-20% of the value, in exchange for turning the money "white".

If the money was stolen and the people who took it aren't stupid, I don't see how someone is ever going to find it.

<comment><USER33> Of course, the more wallets you create and sell, the higher the probability that at least one of their buyers is stupid.

</comment></comment><comment><USER34> So if the bitcoins are seized by some government entity....wouldn't that make the total value of bitcoin go up? Supply and demand and all that...

Again, I know very, very little about bitcoin or economics in general.

<comment><USER35> Bitcoins have no intrinsic value. They only have value in trade.

If I started my own currency called a superdollar, and I had the only superdollar in existence, it would be worthless, despite the fact that it was very rare.

If a foreign entity can make the bitcoins you have disappear, that leads to less confidence in your ability to use the bitcoins for trade. The fact that there's fewer out there doesn't mean yours are more valuable. The number of bitcoins has been constantly increasing, yet the price has been going steadily up as well. That's because they've become more trusted, more usable. More places will accept them in trade, and more exchanges exist.

When places like Mt. Gox fail, or fear that foreign entities have the ability to essentially rob the banks with impunity, it makes the currency less trusted.

Consider this. The government issues a currency called digibux. They are matched to the USD, you can buy one digibuck for 1 USD, but they are limited in volume, only so many are offered. Looking at this naively, digibux has the same value as USD. Now consider the following happens, the government takes down a giant drug operation, and invalidates all of the digibux that were involved in the operation. A friend of yours who was a pizza delivery guy has hundreds of dollars removed from his digital wallet because they were tips from people who had participated in the drug trade.

Now you're sitting with 10,000 digibux, and you know that the government is pleased with the results of the previous sting and wants to set up more operations like that. Someone offers you 8,000 USD for your 10,000 digibux. You know that the 8,000 USD can never just vanish.

The number of digibux in circulation went down. But did that make the total value of digibux go up?

<comment><USER34> That's an excellent explanation and I appreciate it. I'm sure you've simplified some, but it makes sense to me.

</comment></comment></comment><comment><USER36> There have been hints that MtGox's losses were due exploitation of the transaction malleability issue.

I don't know if it's possible to identify (from the blockchain) transactions that have been altered in a way that exploits the malleability issue but it should certainly be possible to identify pairs of transactions with identical startpoints, endpoints and sizes (i.e. number of bitcoins).

If it turned out that pairs of such transactions turned out to come from MtGox's wallets to third-party wallets, that would probably be a good starting point.

<comment><USER18> I would be surprised if that was simply a ploy by Mt. Gox to deflect blame from their own ineptitude.

</comment></comment><comment><USER37> So what happens next?

-The government has no inclination to interfere (even though many US citizens lost their money) as they were against it (if not outright criminalizing it).

\- The lost money, even if recovered in full, would not be the same. The time lost is money lost. Besides the emotional shock and pain people had to take.

\- Someone somewhere is sitting on that money, and it will have value, because people won't stop trading Bitcoin even now.

I know people are not ready to take any criticism of bitcoin, but here it is, what needs to be fixed about it.

</comment><comment><USER5> Since the story seems to be that this has been going on for years without anyone investigating, I'd guess that most of them are long since laundered and distributed between various innocent bystanders. Even if we could trace every single uBTC to it's current location, the percentage actually held by those responsible has got to be very small.

</comment><comment><USER38> Somewhere in the blockchain, probably divided into smaller chunks. The way Bitcoin is set up, you can follow transactions, but it's very hard to track buyers/sellers. It's a paradox: Bitcoin's strength is that it's untraceable and unregulated, but in cases like this those exact strengths are pitfalls at the same time.

<comment><USER39> That is not a paradox at all. Bitcoin as a system is performing exactly as designed here (barring possible wibbly wobbly "malleability" bugs).

</comment></comment><comment><USER40> Wouldn't the sheer number of coins involved make tumbling services almost useless. What is the volume that a single tumbler gets per day? If you put in tens of thousands of coins, and there are only a few dozen coins in the Tumblr that day, your coins are going to be most of what comes back.

<comment><USER41> > Wouldn't the sheer number of coins involved make tumbling services almost > useless.

Sure, if they were all stolen and tumbled at once. The descriptions of a cold storage "leak" suggest that if the loss was due to theft, it was a gradual over an extended period.

</comment></comment><comment><USER42> They are most likely being held by the U.S. Government.

[http://www.reddit.com/r/BitcoinMarkets/comments/1z2xo5/specu...](http://www.reddit.com/r/BitcoinMarkets/comments/1z2xo5/speculation_the_us_government_has_control_of_goxs/)

</comment><comment><USER43> [http://falkvinge.net/2014/02/28/the-gox-crater-crowd- detecti...](http://falkvinge.net/2014/02/28/the-gox-crater-crowd-detectives- reveal-billion-dollar-heist-as-inside-job/)

</comment><comment><USER44> Instead of a blacklist which is tantamount to centralized regulation, there can be a concerted effort by the community to publicly shame people using these coins, or tumblers, merchants, services, etc. which accept them.

</comment><comment><USER45> Wouldn't it be funny if the lost bitcoins---were all the result of someone forgetting where they put the key? So not stolen, just literally lost? Talk about a major 'oops' moment.

</comment><comment><USER46> Crypto currency news @ [http://cryptocurrencylive.com/newest](http://cryptocurrencylive.com/newest)

</comment><comment><USER47> "Lost" is such a harsh word. They are still here, in the blockchain.

</comment><comment><USER48> Things like these are bound to fall. People should have predicted this risk.

</comment><comment><USER49> I have to go with the following answer: in someone's pocket.

<comment><USER50> A pocket of someone who had means, opportunity, and motive? Hmmm...

<comment><USER11> If you're thinking Mark Karpeles, he doesn't really have motive as he's likely going to go to jail.

However, an employee or contractor at mtgox who figured he could cover his tracks could have stolen them

</comment></comment></comment><comment><USER51> To reply to a recurring line of thought, Bitcoins are not atomic entities with serial numbers like dollar bills. You can't say "Bitcoin #AE472b was stolen" and then trace it through its life, or blacklist it.

Instead Bitcoin is a ledger that details wallets and accounts. The origin of balances came from mining, and then people made transactions that, on the official ledger, transferred some or all of those amounts to other wallets. And on, and on, and on.

Hypothetically, if the community were foolhardy enough to trust someone's list of "recipients of mislaid money" wallet ids, you could blacklist those wallets, or even, through group agreement, force transfers back. But that's where tumblers come in: Tumblers are group wallets that take transactions in from all sorts, and then distribute them anonymously to new wallets you control (after a service fee, of course). Anyone hiding their tracks will of course have used a tumbler, often anonymously run on the Tor network. Do you blacklist or reclaim from every wallet that took an output from a tumbler?

Bitcoin would be toast. Tumblers are something that legitimate users of the currency make use of. You won't get the cooperation of tumbler operators because they are themselves engaged in a very serious crime.

So the trace-ability claim repeatedly being made just doesn't hold when you have legitimate and illegitimate transactions by the millions all intermixed. When bitcoins are transferred...game over. Give up on that thought.

<comment><USER52> In this particular case, are tumblers viable? If I understand rightly, the stolen coins here are a significant percentage of the amount of bitcoins outstanding.

<comment><USER51> Supposedly this looting went on for years, death by a thousand transfers. It will have dissolved into the sea by now.

</comment></comment></comment><comment><USER53> Does it matter?

Edit: Not "does it matter that they are lost", but rather " _since they are lost_ , does it matter where they are".

<comment><USER54> Well, yes, to a lot of people - both those who lost money in the affair (some people vast amounts), and also to anyone interested in following the development of BTC - if this was theft, how can we prevent repeat incidents to reassure potential Bitcoin buyers; if it was a failure in the technology, what can we do to repair that to make Bitcoin more secure, or if there was some government or official organisations involved, why did they interfere and what're they up to?

<comment><USER53> Too glib I suppose, I just meant that if the coins are "out there" they're not actually recoverable, are they? If a bunch of sand falls out of my hand on the beach, those grains didn't disappear but I'm never getting them back again. Then there's the very real question of whether it actually is theft. I would argue no, in the sense that downloading a song isn't theft.

You play in dirt, you get dirty. You want an unregulated purely digital currency with irrevocable transactions, you know it's going to sting if you lose some of it.

</comment></comment></comment><comment><USER55> What if Satoshi Nakamoto stole them?</comment>


Closure Compiler: Javascript to (better) Javascript compiler - <AUTHOR> http://code.google.com/closure/compiler/

<comment><USER2> 569 days old. <http://news.ycombinator.com/item?id=924426>

</comment><comment><USER3> This isn't even for a new version or anything, old...

</comment><comment><USER4> How comes this is new again?

<comment><USER5> Yes, this was released years ago.</comment></comment>


Yes, Randi Zuckerberg, Please Lecture Us About `Human Decency' - <AUTHOR> http://readwrite.com/2012/12/26/yes-randi-zuckerberg-please-lecture-us-about-human-decency

<comment><USER2> Yes, it's ironic. It's a high-profile example for the legitimate discussion of what level of privacy can be expected from a company that's supposed to both respect our privacy and make a profit off our personal data.

But you don't choose your family.

</comment><comment><USER3> Wow, is this ever a big bag of mendacious tripe. I have no love for the Facebooks, but the OP's tactic of tarring Zuckerberg with her brother's company's actions is utterly without merit.</comment>


How Heap Built an Analytics Platform That Auto-Tracks Every Event - <AUTHOR> https://stackshare.io/heap/how-heap-built-an-analytics-platform-that-auto-tracks-every-user-event <comment><USER2> Heap CTO here. I'll be around for a little while and am happy to answer any questions you have.</comment>


Making Ads and Pages More Transparent - <AUTHOR> https://newsroom.fb.com/news/2018/04/transparent-ads-and-pages/ <comment><USER2> The tone of discussion on HN around this issue seems to have become completely cynical and atypically nasty. Come on, it's a good thing fb is improving and regardless of your stance on the site you cant deny it does a lot of good for a lot of people and seeing it improve on privacy and transparency is a good thing.

<comment><USER3> > you cant deny it does a lot of good for a lot of people

I'm not really interested in having a value judgment discussion of Facebook here, but it really annoys me when people assume this. At least have an open mind enough where you can imagine someone thinking different from you. It really doesn't take that much imagination or empathy to see why some people view it as, yes, completely and totally a net-negative on the world, regardless of whether you specifically believe it or not; I think the good that facebook does do is both incidental and replaceable.

Besides, c'mon, how can you be "nasty" to a corporation? People publicly complaining is probably the only way this change happened in the first place.

<comment><USER4> > some people view it as, yes, completely and totally a net-negative on the > world [...] I think the good that facebook does do is both incidental and > replaceable.

OP wasn't claiming that Facebook is a net positive for the world, just that it indisputably provides a valuable service for at least some people[0] and improving the privacy features is only a good thing. It's unproductive and misguided to attack Facebook for this.

[0] [https://www.buzzfeed.com/annehelenpetersen/ex-flds-new- chapt...](https://www.buzzfeed.com/annehelenpetersen/ex-flds-new-chapter)

<comment><USER2> Exactly. I am personally all for replacing it with open source decentralized options, I am even working to further that cause, but do you actually think that'll happen anytime soon? Network effects are not so easily replaceable...

</comment></comment></comment></comment><comment><USER5> This is amazing! I love that they're adding the ability to see:

1) which campaign or PAC bought the ad

2) all other ads by that buyer

3) how much that buyer spent on this ad and all other ads

Seriously, what other platform provides this level of transparency into political ads? It's unprecedented.

Also, it doesn't matter if you use or like Facebook--literally tens of millions do in the US, and they all have a vote. This is a win for democracy.

<comment><USER6> Found the Facebook PR people

<comment><USER7> This breaks the site guidelines. Please read and follow them: [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

You don't have to agree with someone about Facebook but you do need to take care of the commons when posting here.

<comment><USER6> My apologies.

</comment></comment></comment></comment><comment><USER8> Now instead of every third post that in reality is an ad, half of them will be. But clearly marked as ads.

</comment><comment><USER9> What? uBlock already make ads completely transparent

</comment><comment><USER10> What I'd love to see is the ads' targeting information.

<comment><USER11> Click on the "..." above any ad and select "Why am I seeing this?"

</comment></comment><comment><USER12> [https://www.fbpurity.com](https://www.fbpurity.com) adblocking extension

</comment><comment><USER13> There really is a feeling of "too little, too late".

Not in the sense FB cannot make improvements. Of course they can.

What is too little, too late is reversing the direction that the Zuckerberg story has taken.

The media can build someone up and they can also destroy someone.

As the recent Rolling Stone article suggested in no uncertain terms, there has been great damage done to media and journalism (and arguably to society) by having FB as a "filter" between the reader and the news source.

They have not managed the relationships well enough it seems.

Have a look at this article:

[https://www.theguardian.com/technology/2018/apr/06/mark- zuck...](https://www.theguardian.com/technology/2018/apr/06/mark-zuckerberg- public-image-cambridge-analytica-facebook)

Anecdotally I have heard Zuckerberg discussed in the ways described in this article. I have no doubt he was trying to carefully craft an image for the American public.

But, today, who can trust this young man who has the personal lives of billions of people on his servers... now that they have seen _how he reacts in a crisis_? (Perhaps we should say "fails to react".)

There is a certain irony I see in the failure of Zuckerbergs PR team. Someone who has been in PR for many years once explained to me the effect of FB on PR. Needless to say, it wasnt positive. PR traditionally relied on the media and its ability to reach the targeted audience. To a large extent, FB controls this now.

Whether any of this will matter long-term, who knows? Ask Wall Street?

But if and when FB assures us that they have everything under control, I will have doubts. This is an evolving story. We are seeing only the tip of the FB iceberg.

</comment><comment><USER13> This author located in the UK believes FB should be broken up:

[https://www.telegraph.co.uk/business/2018/03/26/zuckerberg-m...](https://www.telegraph.co.uk/business/2018/03/26/zuckerberg- must-ask-help-fix-facebook/amp/)

He believes that Facebook's board is susceptible to Silicon Valley groupthink and with Thiel there is clear conflict in interest due to Palantir.

He argues the board is "feeble" because Zuckerberg cant be sacked.

The author thinks Zuckerberg has made some "stupid" and "arrogant" moves.

For example last year as an experiment, he cut professionally produced news from the main newsfeed in Sri Lanka, Guatemala, Bolivia, Cambodia, Serbia and Slovakia making those countries "beta-testers" for "a political debate free of facts".

He recalls in 2007 he wrote two news stories about FB for a former employer. One was about some software that "connected to Facebook's then-new "social graph" and siphoned off personal information for resale." The other was about an advertiser, Vodafone, who pulled its ads from Facebook because it had been placed on a page promoting the British National Party.

He suggests that because stories like these could easily have been written as recent as last week, it shows how FB's problems are _not new_ and how Zuckerberg has refused to acknowledge them for the last _ten years_ let alone try to "fix" them.

He thinks FB should not be "fixed"; rather, it should be "broken and remade".

</comment><comment><USER13> He has also announced that he now supports the Honest Ads Act.

[https://www.reuters.com/article/us-facebook- privacy/facebook...](https://www.reuters.com/article/us-facebook- privacy/facebook-backs-u-s-regulation-of-internet-political-ads-idUSKCN1HD2JH)

Perhaps he will announce next that he supports competition.

Isnt it true that before being acquired by FB, WhatsApp charged users a subscription fee and did not show ads?

</comment><comment><USER13> How about making ads _go away_?

FB _appears_ locked in to a business model that relies on continually pushing the limits of invasiveness.

Does that model have a breaking point?

Does FB know where that point lies?

<comment><USER14> I think I would pay $1-2/mo for a custom algorithm that eliminated ads and sorts content the way I want. But Facebook probably makes more money on certain users then that anyways.

<comment><USER15> I am surprised this doesn't get brought up more.

I also would pay $24 a year for a 'premium Facebook' ad free experience.

<comment><USER10> Google tried it. Nobody used it.

<comment><USER16> Google tried to charge for ad-free Facebook?

That doesn't seem likely.

</comment></comment></comment></comment></comment><comment><USER17> There are 2) big problems here:

1) This could have been done long time ago

2) People or bots can still share content as images and there is still lot of fake news being spread in that way.

This will probably help but definitely not a sustainable fix.

</comment><comment><USER18> "We believe..."

Hahaha, no you don't you disgusting liars.

<comment><USER7> As you know, you can't post like this here. You may not owe Facebook any better, but you owe this community much better if you want to keep commenting here.

If you continue to break the site guidelines, we're going to end up banning you. Would you please reread them and use this site as intended from now on?

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)</comment></comment>


How GoDaddy Profits from Expired Domains - <AUTHOR> http://domainnamewire.com/2008/12/03/standard-tactics-llc-how-godaddy-profits-from-expired-domains/ <comment><USER2> NB: This article is from 2008.</comment>


Show HN: Control your 3D printers via Raspberry Pi from the web - <AUTHOR> http://demo.printtopeer.com/

<comment><USER2> I really want a 3D printer- I am hoping to make that happen in 2014- so cool. Maybe they will get a little cheaper and then I am IN

<comment><AUTHOR> We're going to be seeing a lot of innovative 3D printers on the market in 2014, it's really exciting.</comment></comment>


Your Optimizations Don't Apply to SSL Sites - <AUTHOR> http://autoref.com/blog/2013/04/03/ydiw-ssl-page-load-optimization/

<comment><USER2> My name is Neil, I work as Biz Dev for AutoRef. If anyone has any questions or comments about the site, I would be happy to field them.</comment>


A More Secure and Anonymous ProPublica Using Tor Hidden Services - <AUTHOR> https://www.propublica.org/nerds/item/a-more-secure-and-anonymous-propublica-using-tor-hidden-services <comment> mike-cardwell They link to the HTTP version of their Onion address:

[http://www.propub3r6espa33w.onion/](http://www.propub3r6espa33w.onion/)

A bunch of important resources like CSS and images fail to load for me because their Content-Security-Policy dictates that non-https resources should be upgraded. However, the certificate isn't trusted, because nobody (other than Facebook apparently) can get a https certificate for an .onion hostname.

If I change it to https and accept the certificate, it all works fine.

Interestingly, it also works fine when using Tor Browser Bundle. Just not in plain Firefox or Chromium.

[edit] In the TBB console: "Content Security Policy: Couldn't process unknown directive 'upgrade-insecure-requests'" \- So presumably when TBB is upgraded to use a newer version of Firefox at some point in future, TBB users will start to see the same problem.

[edit2] Dropped the guy an email to let him know.

[edit3] Although the website is fetched over a hidden service, they still load resources from lots of non-hidden services into the page, from the likes of Facebook, Google, Twitter and so on. They state in the article:

"Our readers should never need to worry that somebody else is watching what they're doing on our site. So we made our site available as a Tor hidden service to give readers a way to browse our site while leaving behind less of a digital trail."

A _much_ better way to do this than implementing a Tor hidden service would be to stop handing over visitor data to Google, Facebook, Twitter, Disqus, Reddit and Linkedin.

</comment><comment><USER2> If you're using tor browser, what's the best way to discover .onion sites, and (as important, to me), avoid coming across disturbing, unpleasant or illegal material?

Anyone have curated directories of onion sites they'd like to plug?

<comment><USER3> I have been working on something like that -- currently mostly clear web sites with hidden service alternatives, which makes it very few. (Thus, most innocuous sites.)

[https://hidekisaito.com/features/hidden_service_directory/](https://hidekisaito.com/features/hidden_service_directory/) [http://hideki24bd6yof6s.onion/features/hidden_service_direct...](http://hideki24bd6yof6s.onion/features/hidden_service_directory/)

Might expand into some hidden service exclusives, but it's problematic to monitor those sites closely to make sure they don't change to contain something bad.

<comment> mike-cardwell Are these hidden services all provided by the organisations listed, or are some of them run by third parties? It would be useful to have that information on the page for each of them individually. It would also be useful to have links to non-Tor pages where the organisations announce their onion link, so people can verify.

<comment><USER3> They are operated by themselves. I would be reluctant to list ones run by thid-party. And yes, where available I am trying (and middle of) collecting those information as well.</comment></comment></comment></comment>


Show HN: A Slack community for (friendly) bot makers - <AUTHOR> Hi everyone!
I just created http://botmakers.org, a Slack community for people who make "useful, interesting, artistic and friendly online bots".
It's connected with another project of mine, https://botwiki.org/, which catalogs these bots and resources to make them.
I'd really love to see creative people who are into machine learning, NLP, IoT and non-malicious online bots in general, joining in and sharing their projects, tips, useful resources etc.
Thanks! <comment><USER2> Nice! I think it's time for me to create a slack channel for coffea ([https://github.com/caffeinery/coffea](https://github.com/caffeinery/coffea)) ;)

</comment><comment><USER3> Hey This is awesome :)!

I will be sharing some of my bots on here :).

<comment><AUTHOR> Awesome, looking forward to seeing what you created :-)</comment></comment>