macOS 11: copies of dynamic libraries are no longer present on the file system - <AUTHOR> https://twitter.com/mycoliza/status/1275305517066227712 <comment><USER2> No more system dylibs _on the filesystem_ ; only loadable with dlopen (from shipped dyld cache). The title is a shocker that sounds like system libraries are no longer dynamically linked...

Edit: Since this comment is currently at the top, here's a better link to the source: [https://developer.apple.com/documentation/macos-release- note...](https://developer.apple.com/documentation/macos-release-notes/macos- big-sur-11-beta-release-notes#:~:text=built-in%20dynamic%20linker%20cache) (using scroll-to-text fragment[1] since there's unfortunately no usable anchor to the specific entry; not supported in non-Chromium browsers at the moment, in that case search for "built-in dynamic linker cache").

[1] [https://caniuse.com/#feat=url-scroll-to-text- fragment](https://caniuse.com/#feat=url-scroll-to-text-fragment)

<comment><USER3> >not supported in non-Chromium browsers at the moment

Not supported in any-browser-that-follows-the-spec, really, considering scroll-to-text is a google made, unilaterally implemented, nonstandard extension ([https://wicg.github.io/scroll-to-text- fragment/](https://wicg.github.io/scroll-to-text-fragment/))

<comment><USER2> I never said it's a standard. Anyway, I'm interested in providing information about dyld cache (and as an aside explaining why my best-effort link doesn't work in some browsers), not encouraging more tribalistic Chrome/anti-Chrome debate, so we can stop right here.

</comment></comment></comment><comment><USER4> Not a macOS dev but maybe one can clarify: is the title "No more system shared libraries in macOS 11" actually true? The documentation reads to me as a restriction on how you _read_ dynamic libraries (is using only dlopen controversial here? also just trying to understand), not on which system libraries are actually there. It seems dlopen with custom system dylibs would still work if there is also a means to get your dylibs in the system cache? Based on that piece of docs alone I see no reason to grab my pitchfork just yet.

Anyway, I was expecting a few shitstorms to start happening over macOS 11. Apple not announcing any major deprecations (edit: or removals) for this transition - even OpenGL/CL is still there, depecrated - was suspicious.

<comment><USER5> You're correct. For 3rd-party provided dylibs, it also isn't necessary to get them into the system cache.

dlopen() will look for the dylib first (as today), and if the file doesn't exist, it'll look in the shared cache.

So the only people this actually impacts are those who stat() system-provided dylibs before calling dlopen(). They should just skip the stat(), and go straight to calling dlopen().

Certainly not worthy of the end-of-the-world vibes in the twitter thread...

<comment><USER6> Classic linking uses a path to a library at link time. I suppose Apple may have patched ld to work around this choice, but it still begs the question — why change this? Who was it hurting?

<comment><USER7> > why change this? Who was it hurting?

Performance.

<comment><USER6> Can you elaborate beyond a single word? It is certainly not immediately obvious to me how this benefits performance, or I wouldn't have asked.

<comment><USER7> Here's one optimization: [http://sealiesoftware.com/blog/archive/2009/09/01/objc_expla...](http://sealiesoftware.com/blog/archive/2009/09/01/objc_explain_Selector_uniquing_in_the_dyld_shared_cache.html)

</comment></comment></comment></comment></comment></comment><comment><USER8> Isn't this the model that has been encouraged on Windows forever with COM, WinRT and .NET etc? When you consume an API in one of those environments you don't have to worry about the location of the physical assets (library files).

I don't see the big deal as long as app local copies of e.g. curl can still be used

<comment><USER9> How does it work on mac? Do you have to specify the full path of the library to load it?

<comment><USER10> In practice it's transparent, like using a static library. The linker handles it all for you during compilation: it stores the paths at a special section in your executable, and a injects a _dynamic linker_ in your code.

The paths can be either absolute (for system libs) or relative (useful for distributing Bundled apps).

The cool thing is that you can see those hardcoded paths using _otool -L_ and you can modify them using _install_name_tool_. Useful for debugging misbehaving closed-source tools.

</comment></comment></comment><comment><USER11> This is mildly interesting but not much more than that. Who cares if the set of system libraries are available in a series of separate dylib files, instead of being packed together in one mega archive?

Most comments here on HN seem to misunderstand what this is.

<comment><USER12> People writing third party linkers or debuggers is one.

I often dig at shared libraries using tools like nm to see what functions are where.

<comment><USER11> I'm sure there will be a way to unpack the mega archive and run nm (or maybe even run nm directly on the mega archive). Relax :)

<comment><USER12> I never said I wasn't relaxed about it. I don't even use a Mac much.

But the platform does seem to have been in a multi-year process of technical decline, and much of that does speak to a "we know better than you, and everybody else" attitude.

<comment><USER13> A number of the changes that Apple has been making seem to be security related. One reason to just dlopen() rather than stat() and dlopen() is the race-condition, which an attacker could use to get a program to use the wrong library. Similarly macOS' locked-down root partition. Checking hashes of binaries is also for security, to make sure the binary you're running is the one the developer thought they were giving you. So on the one hand the platform is in "slow technical decline" yet we (HN) claim to value security. It seems to me that the platform is doing well technically. We all remember the mess Microsoft had 10 years ago with security vulnerability du jour; Apple seems to be pre-emptively protecting its users. I submit that the "technical decline" is really "macOS is changing from a freewheeling Unix system to a secure system" and people here want to be cowboys and artists with their own private filesystem canvas. I understand the frustration, but Linux still exists. Apple isn't in the business of making a dev playground, but a computer that Just Works for people. It seems to me there isn't a technical decline, it's that HN is revealing itself to value the plasticity of traditional Unix over security (now that security has gotten good enough). I expect that SELinux has similar chafing restrictions, the only difference is that Linux is more of a set of parts so you get to (must) choose how you put those tools together.

<comment><USER12> > One reason to just dlopen() rather than stat() and dlopen() is the race- > condition

But dlopen() implies code execution all the time, and stat() does not.

A good way to close this race condition, by the way, is to have a dlopen-by-fd API [FreeBSD has fdlopen], and a single call to open(2) resolves the race condition inherent in referencing the filename multiple times.

But to your larger point... It seems there is a crowd that will kneejerk dismiss any criticism as "it's for security". And any implementation bugs (such as introducing massive delays when executing programmatically-generated shell scripts because they need to be hashed and sent to a server, as was an HN headline a while ago) are also justified. I think there needs to be greater skepticism than this about how secure these efforts really makes the system, or if they are just throwing buggy stuff at a wall and applying post hoc justifications.

</comment></comment></comment></comment></comment></comment><comment><USER14> If I understand correctly, this is just the same behavior as iOS's "dyld_shared_cache" which is basically all the system shared libraries stuffed into a single file.

[https://iphonedevwiki.net/index.php/Dyld_shared_cache](https://iphonedevwiki.net/index.php/Dyld_shared_cache)

<comment><USER7> Correct, all the system libraries can be now found in the dyld shared cache can be found in /System/Library/dyld/dyld_shared_cache_x86_64(h) (it's moved in Big Sur!).

</comment></comment><comment><USER15> Are those guys in the twitter thread looking for an excuse to vent? It's a minor annoyance at best, and with security/speed benefits...

<comment><USER16> Yeah I mean what system libs do people even use?

Does this affect homebrew?

</comment></comment><comment><USER17> Good. Apple is basically the only entity seriously looking at dynamic linking performance these days. We can do a _lot_ better in the ELF world. We should not only copy dyld's closure cache, but also teach the kernel to do relocations on demand, like NT does. A relocated data-segment page should be a _clean_ page, not a dirty page!

</comment><comment><USER18> To think, the Amiga was doing something like this in the 80's. The "OpenLibrary" call would transparently access shared libraries either in ROM, already loaded into memory, or on disk.

<comment><USER19> Well ARM is a 1980s technology so seems apt.

<comment><USER20> x86 is 1980s. POWER is 1990s. MIPS is 1980s. Sparc is 1980s.

What would you prefer they use? Itanium? RISC-V?

<comment><USER21> Itanium is 2000s. RISC-V is 2010s.

Apple could make a great leap forward by adopting the Mill, an ISA so novel that it hasn't even been released yet!

<comment><USER18> Too bad Alpha died. Those machines were like lightning (for the 90's, anyway.)

<comment><USER20> IIRC even Windows NT could run on Alpha. I wonder if computing would've been different had we gotten a modern 64-bit architecture with very little legacy become commonplace in the 90s.

Makes me think of the Tanenbaum quote from 1992: "Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5".

<comment><USER18> Yes, Digital Unix, OpenVMS, and Windows NT all ran. You could also run Linux and FreeBSD. I worked at a DEC shop for a while in the late 90's. Alphas were speed demons. This was right before Compaq bought DEC. After that, I think things started going down hill...

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> I wonder how many years we've got where you're still able to _read_ the big mega archive...

Someday it may sit in some kind of "protected enclave", mapped into your process with "execute-only" permission for code, and maybe graded protections for its data as well, so you can't debug, trace, instrument, reverse engineer or otherwise get to really know the system libraries to see what they are doing and learn from them.

The trend has been that way for a while. For the moment, that kind of isolation is done at process boundaries, on devices that have enclaves.

There is no technical reason why that kind of isolation cannot extend inside processes, for a company that designs its own CPUs. For the same kind of "black boxes" as we already have inside mobile devices, but with faster API calls and data exchange than doing it across processes boundaries.

</comment><comment><USER23> Likely an unpopular opinion: not everything has to be a file. UNIX removed a lot of obstacles and helped usher in the era of computing accessible to individuals -- but we can't keep relying on old paradigms when it's now clear (with the benefit of hindsight) that it's not a be-all-end-all solution.

Filesystems are awful databases and I believe everyone who was a programmer for some time realizes this. The lack of ACID being at the top.

The sooner we move to specialized APIs for, well, everything, the better off we're going to be.

\---

As one recent example, the PS 5 will just directly load 3D artefacts from the SSD storage to the GPU when the corresponding API is called. This gives Sony peace of mind that people won't be coming up with 100+ ways of doing it by themselves which Sony will then have to support for the entirety of the PS 5 lifecycle.

We the programmers have demonstrated to ourselves, time and again, that too much freedom can actually be a bad thing.

It's okay to move away from the "everything is a file" philosophy. If anything, I'd love to see a Linux-like OS that utilizes sqlite3 for, say, the entirety of the current `/etc` directory and uses sqlite3's backup/changeset APIs to do incremental and point-in-time backups. Sure it's little less transparent but you can't ever capture an inconsistent snapshot. That has to be an improvement, right?

\---

EDIT: I suppose people can't find a link between my comment and the topic but my point was that moving to dedicated APIs -- and not relying on the filesystem -- for various services (like loading a dynamic library) is a good thing because the "everything is a file" paradigm isn't as bulletproof as it's made out to be (also because "stat" \+ "dlopen" one after another are race- condition prone as others pointed out).

I'd love to hear the downvoters elaborate their reasoning.

</comment><comment><USER24> I think this is a good change. It's eliminates a potential avenue of accidentally doing the wrong thing but not noticing because it "works on my machine."

<comment><USER6> In what scenario does it eliminate this?

<comment><USER25> I have had to deal with bugs in the past caused by people using incorrect case for paths to dlopen(), etc.

Lots (I wouldn't be surprised if _most_ ) osx devs use case sensitive filesystems, but the default in case-insensitive, and so dlopen(path) fails if you have (say) "/system/..." instead of "/System/..."

</comment></comment></comment><comment><USER26> Can anyone come up with a reason this would be preferable to having just the index cached for the linker and handing out mapped memory / open files instead? What's the benefit here over essentially ld.so.cache with bells and whistles?

<comment><USER27> It reduces disk space.

Historically the dyld_shared_cache has been a pre-bound copy of most system libraries that is mapped into memory once and then shared across all processes. It was updated automatically by the system at various times, and if a given system library was determined to be newer then the dynamic linker would simply load it from disk. The result of this was that for most system libraries you ended up with two copies on disk: one at the normal location, and one within the shared cache. Now only the latter copy exists, and Apple ships it directly rather than creating it on each machine from the copy of the system libraries that they ship.

<comment><USER28> Disk is cheap, and we're not talking about a huge amount of space. Surely there's a better justification.

<comment><USER29> On lower end laptops it isn't cheap. Also these savings add up - a few hundred MB here and there and you end up with a system that's 10GB lighter on a laptop that has just 128/256GB of space.

</comment></comment></comment></comment><comment><USER30> Sorry, but the /usr model for compiling is out of date / flawed. It isn't about "me" it is about "you" the target for running the executable.

For many years, macOS has supported being a cross compilation environment for multiple platforms and multiple OS releases.

This means that include files and libraries for the target OS and platform are not stored at the "host filesystem" paths that were used in the 1960's, 1970's and 1980's... (an embarrassingly long list). Include files and references to libraries are available in the SDKs. One should use the SDK path as a prefix for the include and library paths - something that most GNU tools, and other open source projects have supported for a very long time, but sadly a little inconsistently. There are runtime tools and recipes that can be used to get these paths, including for "myself".

All compilation on macOS should be considered as cross compilation -- because macOS simultaneously supports multiple architectures and OS versions.

This really is a good abstracted model for all compilation.

This has benefits! Install time and disk space usage are reduced for most customers and developers. Developers on x86_64 do not need the aarch64 content in /System, /usr to compile. Install the SDKs for the targets you wish to compile for.

</comment><comment><USER31> Frees up a gig or two of disk space. Good.

<comment><USER6> Frees up cheap disk space by moving the library contents to expensive RAM? That doesn't seem like a good thing. And it also doesn't seem possible — you want system libraries to survive reboot. Presumably these files exist somewhere on disk, just hidden.

<comment><USER32> The dylib cache is stored on disk. It's saving disk space by only having that copy of the libraries instead of two copies.

<comment><USER6> What would the second copy be?

</comment></comment></comment></comment><comment><USER33> two questions

Does this break pkg-config?

What about fishing for dylibs in .bundle directories that may be installed in multiple locations?

</comment><comment><USER34> So the title is wrong? The libs are just not directly accessible from the file system

</comment><comment><USER35> I assume this is for privacy (an app can't fingerprint you by looking at which libraries you have) but macOS is starting to become a terrible dev environment. Why are they locking down my device from me?

<comment><USER36> When you say "Starting To" I presume you mean from about 2015 on. It's clear Windows is trying to pick up slack and also be cloud developer friendly with WSL integration.

Apple sticking with Intel and now reverting to a terrible proprietary cpu architecture, locking software down more and more, releasing pro versions with inadequate options and keyboard all acts to ensure they lose their status as top developer environment

Before they dropped powerpc for intel, no one would have considered using a mac for dev work.

It's clear they don't understand the developer market at all or are only interested in Mobile because the revenue is insane.

They had a good ten years as the best dev environment but as they say "The King is dead, long live the King".

<comment><USER15> > _terrible proprietary cpu architecture_

Err, there are more cpus with ARM than x86 by an order of magnitude...

It's also less proprietary...

> _Before they dropped powerpc for intel, no one would have considered using a > mac for dev work._

Huh? Where did you get that from? OS X Macs where quite popular for dev work pre-Intel, popular for web devs, and with good Java support...

<comment><USER37> I'm guessing when your parent said "cpu architecture" they meant precisely that and not "instruction set architecture". The ISA is ARM, sure, but the CPU architecture is Apple.

</comment></comment></comment></comment><comment><USER38> How common is this technique for loading libraries? How about in the kind of POSIX tools that are available, but not exclusive to, on mac os (sucha as bash, termux, vim, git, apache etc)?

<comment><USER39> The old code checks for the filepath to be present before attempting to dlopen it. The new way requires you to dlopen the path. This is very meh because dlopen already executes code from the library, so if you didn't want that, good luck.

(glibc and some other core libs like openssl like to detect plugins by probing the paths for libs and only loading them when necessary)

<comment><USER38> Yeah. So I understand it has been considered best practice to check the file before opening it? Does that mean we can assume that most well-written programs will follow the pattern and break on mac os?

I would have thought that even if Apple did make this change they could trap the fopen or whatever and return something useful based on a heuristic? It wouldn't be the first time that they put exceptions and heuristics in for software compatibility.

<comment><USER40> > So I understand it has been considered best practice to check the file > before opening it?

Check it... for what?

<comment><USER15> For presence...

<comment><USER40> Why do you need to separately check for presence before you use dlopen? If it's not there dlopen will give you a nice error message - no need to check yourself.

Are you currently checking files are there before you dlopen them? How do you avoid a race between the stat and the dlopen? What happens if the file is removed between them? Seems broken and you shouldn't be doing this in the first place.

<comment><USER39> It is usually unlikely that a file will be removed between stat and dlopen, such errors occur rarely. Even more rarely when the file happens to be a systems lib or plugin lib. Some errors occur rarely enough that it isn't worth worrying about.

</comment></comment></comment></comment></comment></comment></comment><comment><USER41> Is there a good term which distinguishes a general-purpose OS (Unix, Windows, Plan 9, etc) from operating systems like Android, iOS, Windows RT, etc? The term "operating system" is being overloaded to ship systems which are really more of a graphical shell than a classical operating system. The moves to lock down operating systems, ostensibly made for "security" reasons but conveniently centralizing power and authority with the vendor at the same time, are being marketed to consumers as the same kind of product as a conventional operating system while in fact being profoundly different.

<comment><USER7> I think you're in the wrong thread.

</comment></comment><comment><USER20> Pretty similar to what they do with kexts on iOS.

<comment><USER7> iOS does this for dynamic libraries too. Actually, it's been doing this for many years.

<comment><USER20> Didn't know that, I've never really done any serious iOS dev. Only knew about the kexts because it came up in a job interview.

</comment></comment></comment><comment><USER42> Somebody asked on Twitter, "doesn't this break all of Brew?"

Does anybody know?

<comment><USER43> I don't see why, Brew just uses the standard compilation tools any other software on OSX uses, so it'll work the way any other tool works

Brew either uses the system libraries (which still work) or compiles its own version (which is not affected by this)

</comment></comment><comment><USER44> Not to be paranoid, but with this change what stops Apple from silently shipping libraries with backdoors/surveillance if requested by law enforcement. How would a security researcher catch the change without being able to examine the library files?

<comment><USER45> They don't need to ship a backdoor because all files in iCloud (photos, documents, etc.) aren't E2E encrypted anyway. According to Reuters they readily share that with the government, despite all their FBI-thwarted-yet- again posturing in the press.

Not to mention they could just backdoor the kernel, and since that's not open- source, good luck detecting that.

<comment><USER46> And of course they do, surveillance is the law in the US. They are expected to comply.

</comment></comment></comment><comment><USER47> I don't see why it should be any different.

</comment><comment><USER48> How will we write our own libraries, then?

<comment><USER31> As before? This just means there are no longer two full copies of every system library on disk.

</comment></comment><comment><USER48> How would we write our own libraries?

<comment><USER49> I guess just as before, by using install_name_tool to burn the install location into a .dylib (with special vars), and then link against it? The question seems rather, how to link against system libs if these are no longer palpable files.

</comment></comment><comment><USER50> Clearly a change for privacy reasons.

You aren't allowed to go fishing around the system anymore.

<comment><USER51> > You aren't allowed to go fishing around the system anymore.

Sure you can. You'll now `stat` around for everything you did before, but now you'll have to `dlopen` the system libraries instead. Surely no privacy win?

</comment></comment><comment><USER52> For end users, this transition will be fairly seamless. For developers, let the nightmares begin.

</comment><comment><USER53> If I read this correctly, this is absolutely bonkers. Basically the "System libraries" do not exist as files anymore? So they just deprecated normal dynamic linking for a subset of libraries? But as I know the Mac folks around there, they are going to swallow it. Because, uhm,..., It's Apple.

<comment><USER40> > this is absolutely bonkers

Why do you care if the files are on the disk or not though? What are you using that for?

<comment><USER53> For linking.</comment></comment></comment>


Opera's iPhone Browser Is Terrible - <AUTHOR> http://www.businessinsider.com/operas-iphone-browser-is-terrible-2010-4

<comment><USER2> Not a very in-depth review.

The consensus seems to be that if you're ever on a really low bandwith connection, or you need to watch your usage because you're roaming or whatever then it's great.

I think people are confused and think they're running a platform that lets you replace the main browser. Instead you can only complement it which, e.g. in the situations above, Opera clearly does.

</comment><comment><USER3> Yeah, to be honest, I think that the reason that Apple took so long in approving the app is that they were too busy rolling around on the floor laughing at it.

</comment><comment><AUTHOR> Sadly I completely agree with this. Slow, clunky, and I feel like my phone took about a 50% haircut on speed. . .

<comment><USER4> No. It is worse.</comment></comment>


An app that finds NSFW photos on your phone? - <AUTHOR> https://itunes.apple.com/app/id1305287901 <comment><USER2> Probably too late for this guy:

[https://www.reddit.com/r/techsupport/comments/3bxyb2/i_accid...](https://www.reddit.com/r/techsupport/comments/3bxyb2/i_accidentally_uploaded_50000_porn_photos_to_my/)

<comment><AUTHOR> Ouch, my condolences :(

</comment></comment><comment><USER3> The whole concept of NSFW is ridiculous and one of the more embarrassing things about the "modern" workplace.

<comment><USER4> How so? Do you not think there is a level of professionalism required in a work setting?

<comment><USER5> How do you define "professionalism"? And for what purposes?

<comment><USER4> I'll take that as a no...

<comment><USER5> That's the "professionalism" word that I object to, not your question :)

You may object to NSFW for a multitude of (better) reasons that have nothing to do with "we're in a context where we work for money".

</comment></comment></comment></comment></comment><comment><USER6> There are a few apps right now that runs offline A.I. (instead of in the cloud) using the new CoreML in iOS 11 from Apple, including general object detection as well. But NSFW is a special unique use case.

Guess when you are a third party app running A.I. across entire user album you can't really do cloud anymore.

Disclaimer, developer of Polarr Album+ here (recently launched [1])

[1] [https://techcrunch.com/2017/11/06/album-organizes-photos- wit...](https://techcrunch.com/2017/11/06/album-organizes-photos-with-a-i- that-runs-on-your-phone-not-in-the-cloud/)

<comment><AUTHOR> Hey, your app looks dope! Will definitely try it out. How do you differentiate yourself from the built in AI that's in the default Photos app?

</comment></comment><comment><USER7> There is another app called Nude that does the same thing. Unclear what differentiates this one.

<comment><USER8> Maybe this one doesn't send the photos back to the company's servers.

<comment><USER9> Maybe.

<comment><USER10> Would be good if there was a way to switch off internet access to apps in iOS.

<comment><AUTHOR> You actually can switch off cellular access of a certain app. You can also use airplane mode while you're using our app. We actually encourage our users to turn on airplane mode while using our app, because we want them to know it absolutely does not use the internet to scan your photos :)</comment></comment></comment></comment></comment>


Xcode 4 ships a buggy compiler - <AUTHOR> http://blog.phusion.nl/2011/12/30/xcode-4-ships-a-buggy-compiler/ <comment><USER2> First of all, all compilers are buggy because all software is buggy. Software has bugs. Deal with it.

Second of all, if you are using alloca to allocate memory on the stack you are asking for trouble. There are so many filthy corner cases to deal with it is not worth it. Figure out another way to do what you are trying to accomplish. This has nothing to do with C or LLVM. This has to do with how a Von Neumann architecture works. [http://stackoverflow.com/questions/1018853/why-is-alloca- not...](http://stackoverflow.com/questions/1018853/why-is-alloca-not- considered-good-practice)

Third of all, alloca() is a compiler intrinsic. The compiler may choose to implement it in any way it wants to. <http://en.wikipedia.org/wiki/Intrinsic_function>

Fourth of all, sending a system function with a size_t of zero is undefined behaviour. This is not a bug. Undefined behaviour means that the compiler may do anything. <http://en.wikipedia.org/wiki/Undefined_behavior>

In general, LLVM does the most optimal thing when it hits undefined behaviour because it assumes that the Clang static analyzer will warn the programmer.

<comment><AUTHOR> > First of all, all compilers are buggy because all software is buggy. > Software has bugs. Deal with it.

This is a _compiler_ we're talking about. Having a "deal with it" attitude is not a good thing to have. If there's a kernel bug that causes a crash would you also say "deal with it" or would you ask the creators to fix it?

> Figure out another way to do what you are trying to accomplish.

This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it.

<comment><USER3> > This is part of the code for the conservative garbage collector which is > supposed to scan the stack for pointers. If you know a better way to do > that, by all means let's hear it.

Why does scanning the stack for pointers need to involve alloca(0)?

<comment><AUTHOR> alloca(0) is used as a way to get the end of the stack. There's a bunch of fallback #ifdefs in the code: on platforms that don't have alloca, it detects the end of the stack by calling a forced-non-inline function which returns the address of its sole local variable, but that assumes that the compiler supports the 'noinline' keyword. In any case, all of versions depend on highly platform-specific behavior. See:

[https://github.com/FooBarWidget/rubyenterpriseedition187-330...](https://github.com/FooBarWidget/rubyenterpriseedition187-330/blob/mbari/gc.c#L567-570)

[https://github.com/FooBarWidget/rubyenterpriseedition187-330...](https://github.com/FooBarWidget/rubyenterpriseedition187-330/blob/mbari/rubysig.h#L210-269)

</comment></comment></comment></comment><comment><USER4> "Calling alloca(0) should return a pointer to the top of the stack"

Eh? My understanding is that it's undefined behavior and varies per platform and compiler. Relying on it to return a stack pointer seems like a pretty terrible idea even if it should work.

<comment><USER5> As much as I hate LLVM, and as many times as I've been burned by bad code it has generated, I at least have to agree about this: alloca(0) tends to do random stuff on different systems (in fact, it often seems to be special-cased to clear the alloca area in library implementations).

However, assuming the actual compilation and test results reported in this article are true, I personally don't care what the function does: if (alloca(0) != NULL), then alloca(0) /should not/ return NULL. ;P

<comment><USER6> You lost me at "As much as I hate LLVM."

What's to hate?

<comment><USER5> I am often seen arguing against LLVM on purely philosophical grounds from my asserted position in the world of open devices and jailbreaking; specifically that it, and Clang, are now products heavily funded (nearly owned) by Apple with the goal of decreasing their reliance on a project (gcc) that was relicensed under GPLv3, an event that caused Apple to immediately retract all of their engineers from contributing code, or even merging newer versions. This opinion has been strongly forged after numerous dealings with Apple's open source release department, having to pester them over and over again to get updated versions of gcc, gdb, and WebCore for their various systems (most specifically the iPhone, for which they like to redact all open-source code).

<comment><USER7> So you are basically saying you hate Apple and the way they contribute to OSS (which IMO has been a very significant contribution benefiting many other OSS projects), not LLVM or Clang. Good to have that sorted out... :-/

</comment></comment></comment></comment></comment><comment><USER8> The Clang build shipped (called "LLVM Compiler" in Xcode) is also buggy: it has issues with some floating point operations on armv6 (edit: I think; it might only be THUMB, or THUMB _and_ armv6) builds (for the iPhone). There isn't a non-LLVM GCC build for the iPhone anymore, however, so you'll probably have to choose between this bug and the floating point one when building for iPhone.

<comment><USER9> it helps to turn thumbs off if you encounter that problem on armv6 builds

</comment></comment><comment><USER10> Blocks in Objective-C are also buggy. If you chain 3+ in a row, the compiler craps out

      //Ex:
      [UIView animateWithDuration:1 animations:^{...} completion:^{
        [UIView animateWithDuration:1 animations:^{...} completion:^{
          [UIView animateWithDuration:1 animations:^{...} completion:^{
            //Compiler error here
          }]
        }]
      }];

</comment><comment><USER11> I use gcc for code gen.

The idea to use undefined behavior for optimization is really terrible. Somehow they forget this is engineering project, not in researching. Breaking existing code costs a lot of time and money.

By the way, I don't see their optimization has any impact on the real project I am working on (highly cpu intensive).

<comment><USER12> "The idea to use undefined behavior for optimization is really terrible. Somehow they forget this is engineering project, not in researching. Breaking existing code costs a lot of time and money."

Saying that using undefined behavior for optimization is really terrible is living in a pipe dream if you code in C at all. No performant C compiler does not use undefined behavior to optimize it's resultant code. In fact, GCC does a fair amount of this too.

The real value in using undefined behavior to optimize code is that it leads to a fair amount of layering of optimizations. And the real world tests so a significant improvement in program running speed because of the interaction of optimizations.

The real problem is that most C programmers expect far more defined behavior than the standard actually gives. For a long explanation and lots of examples of this, see the series of blog posts at: [http://blog.llvm.org/2011/05/what- every-c-programmer-should-...](http://blog.llvm.org/2011/05/what-every-c- programmer-should-know_21.html)

BTW, breaking existing code happens all the time with new compiler version releases with LLVM or GCC.

A side note on GCC: back in school we actually had very simple programs that used only STL data structures (all calls being legal according to the lib specs) that would cause seg faults with certain levels of optimizations in GCC. What's worse: it didn't happen in the previous major X.Y version (i.e. the difference between 4.2 and 4.1.) But even on the breaking build it worked with -O1 but not any higher. That's inconsistent behavior in optimizations if I've ever seen it. But to be fair to the compiler: it's likely that the STL made assumptions that you technically can't make according to the C spec. Just like the OP's code. I love Ruby, but using MRI as an example of code that is a correct program is rather extreme. MRI makes tons of assumptions that often lead to noticeable bugs in the interpreter.

</comment></comment><comment><USER13> I tried compiling the code they have in the example with llvm-gcc and it doesn't compile and returns an error?</comment>


The Triangle - <AUTHOR> http://ideqa.blogspot.com/2016/09/the-triangle.html <comment><USER2> If you need to write that many tests for such a simple algorithm, you're going to be spending all your time writing tests and your programs will never be finished.

There are many ways of simplifying this. For example:

 _" You need 3 test cases for one of the numbers being 0. You need 3 test cases for one of the numbers being a negative. ... You need your null case (where all the inputs are 0's)."_

Or, you could just factor out that input validation into a single function, is_valid_length(), that you call on each of the three inputs to make sure that it's greater than or equal to zero. Then, you'd just need to test that function once.

<comment><USER3> I think you've misunderstood the point. The challenge is that someone else has written the code, and you are being asked to produce cases to feed it to test that it gets the answers right. You're not being asked to write the code, or factor the code, or write a function, or anything else like that.

So under those conditions, where the code has been written and it's your job to test it, what is your list of test cases?

<comment><USER2> In either case, I think my main point is still true: if you need to have so many test cases for such a simple program, you'll never finish performing all the tests for a real-world program. If you're testing someone else's program, you'll need to pick a manageable number of test cases that have a high probability of finding the errors. How likely is it that the programmer who wrote this code tests side "a" for being less than or equal to zero, but only tests side "b" for equal to zero and doesn't test side "c" at all? As a tester, I'd assume that if the program catches bad input for one side, it would do so for all sides, and then move on to test other things.

<comment><USER3> I deduce that you've only worked with a limited type of programmer. I have, indeed, tested code written by people who did not do as you suggest. That being the case, I wrote code to produce _all_ the test cases, including all the permutations of the elements. In this case I would produce three numbers in non-decreasing order, and then output all six permutations of them.

I write safety-critical software, and I test safety-critical software written by others. I fully expect _all_ of these cases to be tested, including feeding the program with non-numeric values, negative values, junk, and floating point numbers that are equal under various levels of precision.

If you're not doing this, you're deliberately choosing to sacrifice the program's quality for your time and effort spent testing. That's a choice you can, or course, make, but you should be very clear to yourself, if not your users, that you're doing it.

<comment><USER4>
      > I deduce that you've only worked
      > with a limited type of programmer.

More technically, you _abduce_ that.

[https://en.wikipedia.org/wiki/Abductive_reasoning](https://en.wikipedia.org/wiki/Abductive_reasoning)</comment></comment></comment></comment></comment>


Mutability, Arrays and the Cost of Temporary Objects in Java - <AUTHOR> http://www.cforcoding.com/2009/12/mutability-arrays-and-cost-of-temporary.html <comment><USER2> To me, those results are kind of obvious to anyone who understands garbage collection, array lookups, and method call overhead.</comment>


Devuan Jessie 1.0.0 stable release - <AUTHOR> https://devuan.org/os/debian-fork/stable-jessie-announce-052517 <comment><USER2> Congrats for following through on Devuan. I'm guessing it took _a lot_ of resolve to make this happen.

Should we be worried about the fact that it took over two years to untangle systemd from Debian with respect to Linux in general?

In case someone from the Devuan project is around, what alternate init system should maintainers be targetting now for Devuan? OpenRC, classic SysV init, or something else?

<comment><USER3> > Should we be worried about the fact that it took over two years to untangle > systemd from Debian with respect to Linux in general?

The time it took says nothing about the difficulty of the task. It could be very hard with the best hackers working on it full time. It could be the time it takes committees to reach a consensus.

Even if it _was_ that hard, is it because systemd is so entangled with the system? Or because it makes maintaining a distro so much easier ?

<comment><USER4> > says nothing

you're point is well-taken, but I think it says _something_. It just doesn't _necessarily_ mean that it's a messy, entagled system which is deeply integrated and hard to isolate.

but it does point, circumstantially, in that direction.

<comment><USER5> It might also point into the direction that the people behind Devuan have never worked on a distribution before and needed quite a bit of time to figure out how stuff works.

</comment></comment></comment></comment><comment><USER6> I never understood why the Devuan developers could not just contribute their work to Debian directly. Yes, systemd had become the _default_ init system, but the idea that other developers would oppose contributions that would do nothing but improve interoperability is just absurd.

To me, this whole "we're forking Debian" thing just feels like a strongly emotional opposition to systemd, not rational solution to the init system problem.

<comment><USER7> They were told to by debian. They argued for as long as they could while debian was still 'their' distribution to change the direction systemd would take it. It was clean that wasn't going to happen. Final response; "If you don't like it you can always fork. But you'll never release anything."

So now they have forked and they have released. So now their splitters. Cake and eat it types, what can you do?

<comment><USER6> > They were told to by debian.

I don't follow. Are you saying that representatives of the Debian project refused to collaborate with the Devuan developers with regards to improving init system interoperability?

<comment><USER8> I mean, I think the comment was pretty clear, and that sounds like exactly what they said.

<comment><USER5> What did "Debian" say exactly? Can you link it?

Or are you just stating what you imagine "they" might have said? :)

<comment><USER9> This[0] PCWorld article quotes two Debian list email posts which may clarify what "Debian" said.

From one of the email[1]:

      So, this vote effectively gives systemd the win

And the other[2] shows the result of Debian voting on the topic.

0 - [http://www.pcworld.com/article/2854717/meet-devuan-the- debia...](http://www.pcworld.com/article/2854717/meet-devuan-the-debian-fork- born-from-a-bitter-systemd-revolt.html)

1 - [https://lists.debian.org/debian- ctte/2014/02/msg00338.html](https://lists.debian.org/debian- ctte/2014/02/msg00338.html)

2 - [https://vote.debian.org/~secretary/gr_initcoupling/results.t...](https://vote.debian.org/~secretary/gr_initcoupling/results.txt)

<comment><USER5> So, to quote the subject of [1]: "call for votes on default Linux init system for jessie" Note that it says "default", not "only".

Where does that support the claim that Debian would oppose people working on sysvinit support?

<comment><USER9>
      Where does that support the claim that
      Debian would oppose people working on
      sysvinit support?

In the body of the other[2] email where 'Option 2 "Support for other init systems is recommended, but not mandatory"' was selected by the Debian community. Once this path was chosen, while it theoretically isn't opposition, in practice it was only a matter of time before non-systemd init systems would become increasingly difficult to use in a systemd-leaning distribution (sysvinit or otherwise).

As Manfred Eigen said:

      In theory, there is no difference
      between theory and practice. But,
      in practice, there is.

(source: [https://www.brainyquote.com/quotes/quotes/m/manfredeig211444...](https://www.brainyquote.com/quotes/quotes/m/manfredeig211444.html))

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> It's great that they have released and it's important there are options so users are not locked-in to a single init.

We need to do more to ensure projects do not create lock-ins especially gratuitous ones from single companies that make it difficult for people to use for instance Gnome without systemd.

This kind of lock-in can only lead to bad outcomes and make developing future alternatives and improvements more difficult.

Also its time Systemd defines a scope and decouple and brand any additional functionality beyond an init differently so it makes it easier to inter- operate and pick and choose both for users or distributions. Or you have distributions like Debian for instance voting for an init system but getting all the externalities that were not voted for ending up becoming defacto choices.

</comment><comment><USER11> I am not Linux admin, but I've been using Linux managed by others on servers for many, many years and I have a question: Is that 'systemd' thing is so crucial and important to devote so much effort to create brand new Linux distribution.

I have only vague picture what systemd is doing, I can imagine that there could be something better (as always in IT), but is this really _that_ important?

<comment><USER12> For most users, it wouldn't matter anyway, and I'd argue that that's true even for a lot of the sysadmins. But the argument had a few layers more. Quite a few people agreed that the current init system wasn't exactly the bee's knees, but disagreed on what to use to replace it (systemd, upstart, heck, even Apple's launchd).

There was a rather vocal group that didn't actually care that much about the specific implementation either, but but wanted something in the "Unix spirit", i.e. consisting of a more modular base of small components. Systemd pretty much fails that test as much as humanly possible without being J2EE.

And it all ended with a bad debate on the Debian mailing list. Can't remember all the details, but the Grand Poobahs were accused of acting a bit too grand.

So it wasn't just about the technical merits themselves, but also about philosophy and policy.

<comment><USER13> As a dev/sysadmin, systemd is barely noticeable when you think if it as an init system. When you look at the cool tricks it can do, it's more like its part of the OS than something living on top of it, providing services you'd expect a kernel to provide (albeit not a very Unix-like one, which is what makes people so mad about it).

It's a large and complex beast, doing a lot of different things that make sense in a modern server environment.

<comment><USER14> Ask my users if Apache failing to start on openSuSE because of systemd and lack of ServerName resolution is "barely noticeable".

<comment><USER15> What did systemd do wrong to cause that? Mess up DNS?

</comment></comment></comment></comment></comment><comment><USER16> Some things that need work:

\- The logo. Logos are very affordable. I would consider revisiting this logo, buying a new one or organizing a contest. Believe it or not, many people use t-shirts with the Debian logo and I assume that's some source of revenue stream. I do not see myself wearing a Devuan t-shirt with this logo. Right not it looks like a logo for a UFO cult or some cheap Internet cafe.

\- The information on the landing page should be organized to emphasize what is important for each type of experience. e.g: dividing it into info for users, info for prospect contributors, info for existing contributors, and donation (what and how to donate, and what is done with donations). Try to interleave these roles less and summarize more.

Then, I would like to understand what the key differences are with Debian, also what specifically does "control over your system" mean?

<comment><AUTHOR> Any recommendation on logo designers?

<comment><USER16> A friend commissioned a logo through a website where you get proposals from multiple artists. He had the chance to buy a fantastic logo for a very affordable price. I don't know the name of this website but my HN family here surely knows. Someone?

</comment></comment></comment><comment><USER17> If I just read wiki correctly, they set out with the goal of removing systemd and then kept systemd?

<comment><USER18> Statement from the OP:

> Devuan is about choice. We think people should be able to choose whether to > use a GNU+Linux system with or without systemd.

> Devuan decided to fork not only the base distribution, but also its > governance, because Debian has made it difficult to avoid systemd as init, > entangling the system with unnecessary dependencies and did so despite > widespread community concern. We encourage potential Devuan users who wish > to install systemd to use Debian's installer, Debian's packages and Debian's > mailing lists, all available directly from Debian's mirrors.

<comment><USER19> So they now officially recommend Debian to people who value true init freedom?

<comment><USER20> No,

> _We encourage ... users who wish to install systemd to use Debian._

</comment></comment></comment></comment><comment><USER21> Great to see they are making headway. Wonder about the long term sustainability though, as more and more software such as GNOME3 DE lists it as a dependency

<comment><USER22> There's also Linux life without Gnome. I hope this means more people will try out alternative window managers.

<comment><USER23> Could always use the Window manager that is included in the X-Server source code package: TWM. It's dependencies is basically the X-server.

<comment><USER24> If you have ever used TWM, then you would know that the 'T' stands for Terrible. Fortunately, there are lots of lightweight WMs that are far better. Personally, I use tiling WMs (namely XMonad at the moment), so I could really care less what GNOME, KDE, et al are up to. However, I realize most people are accustomed to stacking WMs and expect something similar to what is provided by proprietary OSes with a similar amount of eye candy as well.

<comment><USER25> Hey now, no need to resort to name-calling. In fact, the "T" originally stood for "Tom", but the name was later changed so the "T" stood for "Tab" (referring to its then-default look of window titles as little tabs on top of windows).

Furthermore, it is _not_ terrible. I've used TWM for more than 20 years. It worked perfectly fine for me when I started to use it, and it still does so today, so I have not seen a need to switch.

</comment></comment></comment></comment></comment><comment><USER26> It's likely that I missed it, but I can't find anywhere that talks about how many packages deviate from Debian. I love what they are offering but I also want to make sure that the ease of use I get with Debian continues with Devuan.

Can we assume that any packages that are not Gnome related from the Debian repos are in the Devuan repos?

<comment><USER24> This video[0] (dated Nov 29, 2016) says 381 forked packages. That's not nearly as bad as it sounds because many individual software projects are divided up into multiple packages.

For example, libvirt[1] produces 9 packages consisting of: libvirt-bin, libvirt-clients, libvirt-daemon, libvirt-daemon-system, libvirt0, libvirt0-dbg, libvirt-doc, libvirt-dev, libvirt-sanlock.

The video is rather interesting for learning about how the project came about and how it works in general.

[0]: [https://www.youtube.com/watch?v=wMvyOGawNwo](https://www.youtube.com/watch?v=wMvyOGawNwo)

[1]: [https://git.devuan.org/devuan- packages/libvirt/blob/master/d...](https://git.devuan.org/devuan- packages/libvirt/blob/master/debian/control)

</comment></comment><comment><USER27> Devuan Jessie with Wicd on a Thinkpad X220. All just works. Enables the non- free repository (iwlwifi drivers installed out of box) if that matters to you.

</comment><comment><USER28> Does anybody know how many people are working on this and how many people are working on the security team?

<comment><USER29> The major contributors are listed here: [https://devuan.org/os/team/](https://devuan.org/os/team/). Either they don't mention packagers specifically or they don't have a lot of them.

They didn't fork too many packages, so security handling should be fairly easy. They plan to offer support for a longer period than Debian. I don't think they'll be able to based on my experience contributing to a slightly bigger distribution (e.g. maybe 30-40 packagers) whom are lagging behind on security updates.

</comment></comment><comment><USER30> The website needs some work. I could gather they were a fork of Debian, but I couldn't find the benefits. I had to come to the HN comments to learn about the systemd controversy. Less important, the mobile experience was not good on Android Chrome. When scrolling, the logo visibility toggles and the page content jumps.

<comment><USER4> at the very bottom of the page it addresses it:

> Devuan is about choice. We think people should be able > to choose whether > to use a GNU+Linux system with or > without systemd. > Devuan decided to > fork not only the base distribution, > but also its governance, because > Debian has made it > difficult to avoid systemd as init, entangling the > system > with unnecessary dependencies and did so despite...

but you're right that it makes sense to put it in a more obvious location, given that it seems to be the reason the project exists.

<comment><USER30> thanks; I missed that

</comment></comment></comment><comment><USER31> [https://news.ycombinator.com/item?id=14419189](https://news.ycombinator.com/item?id=14419189)

</comment><comment><USER32> Nobody wants to hear this, but I have strong suspicions NSA worked with Red Hat to make systemd their backdoor of choice for Linux systems, and I highly praise efforts to offer diversity in in it land regardless if I'm right or not.</comment>


Gamestop acquires Kongregate - <AUTHOR> http://techcrunch.com/2010/07/27/gamestop-kongregate/ <comment> jim-greer Here's a video of me talking about it: <http://www.kongregate.com/pages/kongregate-announcement>

<comment><USER2> Congratulations. I've always enjoyed your product/community (as a gamer, not dev). I hope GameStop does you right.

<comment><USER3> Devs love the site too.

Congratulations Jim, Emily and everyone else.

</comment></comment></comment><comment><USER4> It's pretty interesting to see Gamestop do this deal. In the industry, the consensus seems to be that in 5-8 years Gamestop is going to get killed as we move towards digital distribution platforms.

So the question is, what do you do in the meantime? I don't think keeping brick and mortar stores around but changing the revenue mix will make a big difference. There isn't anything left to really change to. Hollywood Video had some success with Game Crazy (a Gamestop competitor). But now the gaming biz is set to go away too.

I see it as two options:

A. Go out and do deals (Gamestop is debt free and has hundreds of millions in cash) -- Gamestop appears to be doing this with the Kongregate deal

B. Start releasing cash back via dividends and buybacks. Game Group in the UK (similar to Gamestop) pays out a big 7% dividend.

I'm interested in seeing which one ultimately works out. Gamestop could make (A) work, but only if they do more deals, make the right hires, and give them the kind of autonomy and support that is needed to build out an entirely new business from within a dying one.

<comment><USER5> The obvious is to make the transition from retailer to publisher/distributor. Valve was once a pure developer, but they made their transition to digital distribution and publishing and I'm _pretty_ sure they're doing much better now than when they were doing 1 game every other year distributed by Sierra or some other publisher.

It's definitely out of Gamespot's comfort zone, surely, and Kongregate might look like an odd purchase from a fanboy/consumer point of view. But, casual gaming is incredibly lucrative, especially when linked to social networking sites and mobile. I'm sure Gamestop won't stop (ha-ha) at Kongregate. Perhaps they should next go after a big name in mobile, like Gameloft, ngmoco:) or Glu.

I'd actually like to see some consolidation in the casual gaming industry, if for no other reason than to see if casual gaming can be a place for heavy hitting AAA-type publishers the size of EA or Activision, or if it's just the land of the indies and one- or two-hit wonders.

<comment><USER6> They've already purchased another browser game company; Jolt Online, based in Ireland: [http://www.next-gen.biz/news/gamestop-acquires-jolt- online-g...](http://www.next-gen.biz/news/gamestop-acquires-jolt-online- gaming)

</comment></comment></comment><comment><USER7> I worked for GameStop back when they were having a really, really hard time. They were called Babbage's, had recently merged with Software, Etc (also a failing venture) and then filed for Chapter 11. They emerged when Barnes & Noble's Chairman rescued the embers of the company. Soon after, they bought up pretty much all of the competing stores around here (and from what I can tell, in other parts of the country) and seem to be doing pretty well these days. I jumped ship, but it was just a high-school job anyway. They're faring better than I would have imagined.

Acquire-and-grow seems to be their business strategy. I don't know what they do with their online acquisitions, but they seem to gut, revamp and re-brand their brick-and-mortar assets.

Wishing you the best of luck, Jim! I'm glad they're leaving you guys at the helm.

<comment><USER8> A ha! That's what happened to those two chains. I used to love going to them when stuck at the mall. Had forgotten all about them.

</comment></comment><comment><USER9> I've been a long-time user of Kongregate recently worked through their flash tutorials. They were very basic, but well done.

I really enjoy the site, congrats.

</comment><comment><USER10> Congratulations. Kongregate has some sweet addicting games. I would love a blog post from you on the elements of engaging Flash gameplay...</comment>


Tennis Umpires Are Pretty Unhappy About Serena Williams - <AUTHOR> https://www.motherjones.com/kevin-drum/2018/09/tennis-umpires-are-pretty-unhappy-about-serena-williams/ <comment><AUTHOR> This is probably not normal HN fare, but it has a really clear summary of what exactly happened, which I think many HN readers might appreciate.

<comment><USER2> I liked the NYT article[1] better because it clearly illustrates how Serena Williams' opponent did all the right things: played well, made very few unforced errors and, at one point, literally turned her back on the court to keep her focus on the play and tune out the distractions caused by Serena's rants and the crowd's boos.

Everyone should read this article, whether or not they are interested in tennis, because it has a lot of life lessons on how to conduct yourself when everything may not be going smoothly.

It's a pity that Naomi Osaka won the Grand Slam and made history on a number of levels but the focus remains on the poor loser. I wish the press would celebrate her championship win and her classy conduct more.

[1] Serena Williams vs. Naomi Osaka: How the U.S. Open Descended Into Chaos [https://www.nytimes.com/2018/09/09/sports/serena-osaka-us- op...](https://www.nytimes.com/2018/09/09/sports/serena-osaka-us-open- penalty.html)</comment></comment>


Munich open source switch 'completed successfully' - <AUTHOR> http://www.cio.co.uk/news/change-management/munich-open-source-completed-successfully/

<comment><USER2> Seriously this is not getting the attention it deserves. This is a huge achievement. When they started out the world looked a lot different but despite all the doubts and pressure from Microsoft they managed to pull this off.</comment>


The Inexplicable Attraction of Fractals - <AUTHOR> https://medium.com/@SmartzPlatform/the-inexplicable-attraction-of-fractals-9e7f8c829b57 <comment><USER2> Very cool! Does anyone know how exactly fractals are used for image compression?

<comment><AUTHOR> It's well described in the wikipedia article [https://en.wikipedia.org/wiki/Fractal_compression](https://en.wikipedia.org/wiki/Fractal_compression)</comment></comment>


Why Income Inequality Matters - <AUTHOR> http://www.economist.com/node/17929075 <comment><USER2> _"The second, and more important, way is that to become rich in the first place, they typically have to do something extraordinary. Some inherit their money, of course, but most build a better mousetrap, finance someone else's good idea or at least run a chain of hairdressers in a way that keeps customers coming back."_

Or they might have just been more successful at screwing over their competitors; could have lied, bribed, cheated, stolen, slept, or killed their way to riches; could have managed to convince a whole lot of suckers to buy crap that they didn't need or that was even harmful to them.. etc. All tried and true ways of getting rich.

<comment><USER3> It is amazingly arrogant to say that someone could be convinced to " _buy crap that they didn't need or that was even harmful to them_."

What possibly makes you think you have a better idea of what goods and services I need than you do? By what right do you claim to be better equipped to weight utility, risk, short/long term benefits to a consumer, than they themselves are?

Sleeping your way to riches I view as legitimate. The person sleeping is, in some sense, simply trading their services for payment.

As for 'lied, bribed, cheated, stolen, or killed' - those are all already illegal and prosecuted. Would you disagree with my hypothesis that in, say the last 30 years, less than 10% of millionaires are minted through those means? (I'm not sure if that's true - but I strongly suspect it is. If you disagree, I may do the research ...)

<comment><USER2> _"It is amazingly arrogant to say that someone could be convinced to 'buy crap that they didn't need or that was even harmful to them.'

What possibly makes you think you have a better idea of what goods and services I need than you do?"_

You've never heard anyone complain about buying crap that they didn't need? You never seen someone's house chock full of crap that they never use (sometimes never even taken out of the box)? You don't know anyone with a shopping (or eating) addiction?

Or perhaps you're not aware that corporations spend billions on trying to figure out people's psychology so that products could be marketed more effectively (by, say, doing something so important to utility of the product as changing the color of the box its sold in or the font on the front of the box, or the music played in stores as people shop, not to mention slimy marketing techniques such as getting paid stooges to pretend to be consumers while singing praises of the product and company).

Of course, maybe the consumer really does need to be, say, poisoned by cigarettes, or have a burning need to enlarge their male member, and the valiant marketers are just providing a valuable service by making the consumer aware of this great, hitherto unknown need.

 _"As for 'lied, bribed, cheated, stolen, or killed' - those are all already illegal and prosecuted."_

I'm not sure what your point is there. So these means are (sometimes) illegal. And (sometimes) prosecuted. Many people still continue to use them (just open any newspaper on any day of the year).

 _"Would you disagree with my hypothesis that in, say the last 30 years, less than 10% of millionaires are minted through those means?"_

Unless they were caught (or you were personally involved), how would you know? That's not to say that some haven't been caught. But, like roaches, you can bet that the ones that you see are just a tiny minority compared to the ones you don't see.

</comment></comment></comment><comment><USER4> The bigger question is whether, given that real wages in the US have stagnated for the last 20-30 years, the outsize compensation given to elites is a function of productivity gains increasingly depending on them or just an increase in relative bargaining power.

<comment><USER5> Re: Bargaining power - how can "average joes" increase their bargaining power? Especially as unions have a pretty bad name...

<comment><USER6> And why do unions have a pretty bad name?[in the USA] I would argue that it is in large part due to ceaseless anti-union propaganda by the rich and their minions.

<comment><USER7> I've heard more anti-union sentiment from people who had to be in unions to to get a particular job and then were forced to go on strike for a settlement that really only benefited the union leaders or from people who lost their jobs because going on strike caused the company go out of business. Maybe unions do some good, but it's not just the rich who don't like unions.

</comment></comment></comment></comment><comment><USER8> > Rich folk affect the rest of us in two big ways. First, the way they spend > their money has all kinds of ripple effects. Their hunches move markets. > Their consumption supports a whole sub-economy of hoteliers, watchmakers and > financial advisers. And their philanthropy funds schools, pressure groups > and research into tropical diseases.

Article misses that inventions start as only affordable by wealthy people, but that follows into commoditization and everyone gets to benefit from them. People get so envious of what they don't have, failing to notice the asinine amounts of prosperity around us, things the kings of old could have only dreamed of.

Anyways, I am coming to terms with the fact that human nature doesn't like anyone having more... I'll do what I reasonably can to not participate in various redistributions and confiscations, but I'm starting to accept that there'll always be people wanting to do it and attempting it.

<comment><USER9> Is the nigh-universal human characteristic of greater unhappiness with visible wealth disparity than with lower absolute wealth a sign that we need to engineer better humans, or that governments should reduce inequality even at the cost of average wealth?

ISTM either or both could be the case, in parallel or in sequence.

</comment></comment><comment><USER10> tl;dr: The article says that usually rising inequality is a sign of a broken system somewhere, and that governments should fix the brokenness rather than attacking the rich directly. In the US, they blame the banking system. In China, the problem is the laws that prevent migration between countryside and city.

</comment><comment><USER11> I think it's funny that they use the term "Propagandists" when refering to Al- Queda, but "Think Tank" when referring to the USA. Maybe there's actually a difference between a think tank and a propagandist. Can someone elucidate me?</comment>


The secret maps used in World War II - <AUTHOR> http://www.bbc.com/travel/story/20180712-an-ingenious-way-to-hide-a-map <comment><USER2> On a related note I visited Hughenden Manor, near High Wycombe, last year. That was used in WW2 for map making, one of the maps they made were daily specialised target maps for the bomber raids.

They have a 1940s weekend in September where there are a lot of exhibitors and period equipment & 'actors'. There was also a battle demonstration on the fields. It appears to be on 15th and 16th of September this year but doesn't seem to be well publicised at the moment

It's a National Trust property and has a few rooms dedicated to this role, very little was know until recently. It was also Disraeli's home and has quite a lot of exhibits relating to that era too.

[https://www.military-history.org/articles/your-mh-secrets- of...](https://www.military-history.org/articles/your-mh-secrets-of-hughenden- manor.htm)

[https://www.nationaltrust.org.uk/hughenden/features/hughende...](https://www.nationaltrust.org.uk/hughenden/features/hughendens- second-world-war-story)

There is an image of a map, along with other pictures here [https://castlesandcoffeehouses.com/2016/02/13/hughenden- mano...](https://castlesandcoffeehouses.com/2016/02/13/hughenden-manor- winning-the-war-in-the-icehouse/)

</comment><comment><USER3> Pity they only had a blurry tiny picture of one map and no information on how to see some better pictures of them :(

</comment><comment><USER4> Hmmm, the RCAF silk maps we inherited are much more useful. They're topographic maps of a few dozen square kilometers. They're basically hiking maps you're expected to eat if captured.

Granted my grandfather was stationed in London, so maybe the maps of England and other friendly territory were more zoomed in since any citizens you might meet were friendlies.

<comment><USER5> There is a company in the UK that makes something similar today: [http://www.splash-maps.com](http://www.splash-maps.com)

A great gift as you can centre it on your friend's house

</comment></comment><comment><USER6> Hard to believe these were actually useful. They look very "zoomed out" and my guess is that if you're behind enemy lines you'd want to about roads between major cities and hike through the wilderness instead, but it doesn't look like a trail map.

<comment><USER7> Zoomed out is good when you're potentially bailing out anywhere across hundreds of miles of flight paths, and allows sympathetic locals to point out "you're here, and you want to get there" as high-level info.

</comment></comment><comment><USER8> Let's not forget a brief mention of the pointlessness of war and the value of international institutions. Which one of the interviewees in the article also alluded to.

<comment><USER9> If wars were pointless then they would be unmotivated, surely?</comment></comment>


Show HN: LogRocket – Record and Replay for Redux Apps - <AUTHOR> https://logrocket.com <comment><USER2> This does look cool, and definitely illustrates the awesomeness of using redux / immutable state store. What is the pricing of the service like, though? I'd prefer to see that without having to register...

<comment><AUTHOR> OP here- it's currently free as we are looking to collect feedback and see if this is something people want :)

Down the road we will do monthly SaaS pricing based on how much time we save developers.

</comment></comment><comment><USER3> Speaking as a dev this looks really useful, but as a regular person rewatching a browsing session really gives me the creeps. Any plans to provide privacy controls?

<comment><AUTHOR> Hey! OP here.

We provide APIs to censor data before it hits our server, and some privacy- conscious companies choose to use this in QA/staging and not production.

We're looking to add e2e encryption soon which will make it so that _we_ can't read your data. Eventually we want to allow user-level encryption, so that you have to explicitly ask users for permission to view their recordings.

</comment></comment><comment><USER4> This looks a lot more full featured than the 0.18 Elm release I was waiting months for.

<comment><USER5> Well, they probably have an entire team of paid engineers working on it, and a business model to make additional money. Can you really blame Evan for not being as full featured as that?

<comment><USER6> OP said their team is only three people.

<comment><USER7> That's three more than Elm has. (Founder has day job)

<comment><USER4> Really? Elm is an open source project and anyone can contribute. Github shows 81 contributors: [https://github.com/elm- lang/core/graphs/contributors](https://github.com/elm- lang/core/graphs/contributors) (this is just for elm core, the compiler has its own set of contributors)

I think it's fair to criticise the release

</comment></comment></comment></comment></comment><comment><USER8> How does the integration work with Sentry?

Aside, would love to explore if we can make a richer integration. We added some functionality recently which is intended to allow certain kinds of embedded data in Sentry reports (as well as aggregate data).

<comment><AUTHOR> Hey David :)

Right now we are using your JavaScript API to add a URL as metadata on a frontend exception. Could definitely imagine some cool possibilities if you allow content to be embedded in a Sentry report!

Will follow-up over email.

</comment></comment><comment> Desmond-Lim Looks awesome - can't wait to use it on my app. Great product!

</comment><comment><USER9> I would love to see some examples of how the service works, in particular the session video feature. I couldn't easily find any examples on the home page or the Docs page.

<comment><AUTHOR> Good question - we will write up a blog post soon going into details. Here is the tl;dr:

\- A MutationObserver [1] listens for DOM node changes which are logged and re-built in an iframe for replay.

\- We log various window events (mouse, scroll, resize) which are used during the video reconstruction.

\- A Redux enhancer captures state changes - which are sent to a WebWorker, diffed and then logged.

[1] [https://developer.mozilla.org/en- US/docs/Web/API/MutationObs...](https://developer.mozilla.org/en- US/docs/Web/API/MutationObserver)

</comment></comment><comment><USER10> Awesome, but ironic that I had to completely reload the page to get new data, since I'm guessing this is targeted at single page apps.

</comment><comment><USER11> Looks amazing!

Questions for OP: Are you solo founder/worker? How did you get AOL, NBC, etc using your product?

<comment><AUTHOR> Thanks ggregoire! :)

We are a tiny team of 3 out here in Boston. We are also the creators of a React Native developer tool called AppHub ([https://apphub.io](https://apphub.io)) - so a lot of those users offered to be beta testers for LogRocket.

<comment><USER11> That's nice. :) Best of luck with your new product!

</comment></comment></comment><comment><USER6> Hey. The support button on the sidebar doesn't go anywhere. How do I ping you?

<comment><AUTHOR> Hey! You must have Ghostery installed :) (the support button links to our Intercom)

You can reach me at matt at logrocket dot com.

<comment><USER6> Good call! I just whitelisted LogRocket instead. :)

</comment></comment></comment><comment><USER12> This is really cool. It's like a more robust watchsend.com for web.

</comment><comment><USER13> Will it work for other implementations of redux? Like ngrx?

<comment><AUTHOR> Hey tashoecraft - it should! Looks like ngrx supports Redux enhancers, and that it all we need.

</comment></comment><comment><USER14> Amazing! Can't wait to use this in production

</comment><comment><USER15> Are you thinking about supporting Relay too?

<comment><AUTHOR> Hey alisson - we work with Relay apps as well, since you can see GraphQL request/responses, console logs, and a session video.

We definitely help more with Redux because you can view the client-side state at any moment. Hopefully with Relay 2 we can hook into the client-side storage mechanism and help with debugging there.</comment></comment>


Ask PG: What was the topic of your Ph.D. dissertation? - <AUTHOR>

I'm a big fan of your technical essays, so I recently became curious about what you did your Ph.D. on, but a quick Google search didn't turn up anything helpful.<p>(sorry if this question has been answered before, i'm new to this site) <comment><USER2> Continuations. It was actually completely wrong. I "proved" that you didn't want continuations in a programming language, because there were only a few possible uses of them, and they could all be more cheaply implemented using special-purpose operators. The good bits got re-used in _On Lisp_. The rest was crap.

What I _should_ have written about was macro hacking and embedded languages and so on. That was what I really studied in grad school. But it didn't seem theoretical enough to be a thesis topic.

<comment><USER3> _What I should have written about was macro hacking and embedded languages and so on. That was what I really studied in grad school._

I doubt you were the first person to write a thesis which was unrelated to what you spent most of your time studying, and I know you weren't the last. I spent two years researching parallel computing, and then ended up throwing a thesis together out of two months of work on string matching and delta compression.

<comment><AUTHOR> agreed, oftentimes hacking on a problem for a long time enables you to discover another more interesting (or practical) problem whose need wouldn't have arisen if you weren't working on your original problem in the first place.</comment></comment></comment>


Global 'Wana' Ransomware Outbreak Earned Perpetrators $26k So Far - <AUTHOR> http://krebsonsecurity.com/2017/05/global-wana-ransomware-outbreak-earned-perpetrators-26000-so-far/ <comment><USER2> $26K and the spot on every most wanted cyber criminal list on the planet. Congratulations guys, well done!

<comment><USER3> The flaw in their plan is that the intersection of people capable of figuring out how to pay a ransom payment in Bitcoin, and people still using Windows XP, is pretty small.

<comment><USER4> They have very detailed instructions in 20 languages. It's much more user- friendly than most software these days.

<comment><USER5> But their price point was set too high for their market.

Turns out that for a lot of victims wiping their old computer was deemed less expensive than the cost, nuisance, and risk of paying criminals through some shady internet fake money thing to possibly avoid having to wipe their computer.

For anyone with a recent backup of their data, I can't think of why they'd pay.

<comment><USER6> I think you are way underestimating the percentage of people who have good backups of their data.

HN'ers might, but HN would not be a representative sample.

<comment><USER4> A lot of the high-profile systems getting hit are embedded mission-critical systems. They'd be getting some amount of IT attention. And systems that aren't that important might not be important enough to ransom - just wipe and start over.

<comment><USER6> Agreed - I was thinking more of the individuals.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Sure, Silicon Valley probably won't jump on this bandwagon. But it's ok for a lifestyle business to have modest goals.

</comment><comment><USER8> $55k, now. [https://twitter.com/actual_ransom/](https://twitter.com/actual_ransom/)

</comment><comment><USER9> Would they make more money if they demanded $10 instead of $300? While $300 isn't crazy money, it's more than enough to be painful, and definitely feels like ransom.

I wonder how many people facing a locked computer would sigh, say a few choice swearwords, and dig out their cards had it been a relatively low amount.

<comment><USER10> They passed up a good opportunity for price discovery: have the ransomware pick a random number between, say, 10 and 1000 and learn from that for future attacks.

<comment><USER11> They could also make a machine learning model to take into account the part of the world, the hardware model, and other wealth indicators.

</comment></comment></comment><comment><USER12> Is this a point to the downside of bitcoin? Im not against it at all still, but this does prove it to be a viable method of payment for shady business that can't reasonably be tracked... without bitcoin (or other crytocurrency), what methods would be in place to collect this money that wouldnt be easily tracked?

<comment><USER13> Western Union? Scammers have had means of collecting payouts since the beginning of scams.

One interesting counter point here is that the money hasn't disappeared. Literally every cent that has been paid to one of these Bitcoin addresses can be traced through all future purchases by anyone on the internet. The money will, of course, be combined with other amounts as transactions occur but that doesn't kill the trail. If any of it does end up in a wallet which a government can tie to a real person, an investigator can start working backwards. This is no different from marked bills in a more traditional ransom payment. Not perfect, but proven effective.

<comment><USER12> Western Union at least requires ID to recieve money, and you have to go into a location to do so (you cant claim it online) ... so you will be on camera...

Checks and money orders have to be cashed...

Im not ranting against anything, just a curiosity...

</comment></comment></comment><comment><USER14> If this were me, I'd be running away from it as fast as possible.

It's entered meatspace, with players like the FBI, FSB, China (not sure about their acronyms), and anyone else who feels they have a stake.

If you aren't state-sponsored and protected (by a competent state, however corrupt), you aren't going to win against them. Not when you have a physical body, family, and friends to protect.

(And even if you aren't state-sponsored, do you want to be on high-vigilance for 10+ years? No trips abroad? And how do you stay useful enough to maintain that protection? And how, regardless of internal political turmoil?)

P.S. Not to mention, the competent (as opposed to the other) and very resource rich aspects of their intelligence services. Which can add up to a lot of haystack sifting.

</comment><comment><USER15> What a shame. They've surely done many orders of magnitude more than $26k worth of damage. They've done a really really bad job at monetising their impact.

<comment><USER16> True, the damages they have done far surpass the ransom income, but the inflation of the currency itself based on global attacks probably helps them over the long haul. Sort of crazy that bitcoin markets react to ransom hauls in a positive way and to me - that is the biggest danger to bitcoin and a large source of potential revenue.

</comment></comment><comment><USER17> What would be really interesting to me is the reverse-engineering of the outbound bitcoin to trace this back to real/named individuals.

Consider that every transaction is public information - so any bitcoin spent from that wallet has to go somewhere.

A friend threw out a stat for me while we were discussing this the other day that something like 80% of existing wallets are owned within places _like_ coinbase where they are associated with named individuals. (I don't know if that is true, but for the purposes of this strategy it's the assumption I'll stick with)

Anyways - assuming 80% of wallets can be traced by law enforcement to named individuals. Imagine that you set an alert to watch all outbound transactions from any of those three wallets.

After each transaction, do a lookup on the owner of the receiving wallet. If it is a named individual, interview them to find out how they got this money. Who just sent them a bitcoin?

If the wallet is not owned by a named individual, add it to the watch-list. Repeat for all outbound transactions from that wallet until you can trace it back.

I'm interested to know how many steps it would take to arrive at the actual criminal.

<comment> matt-attack If bitcoin were truly that ineffective for use by extortionists, why is it so commonly used? Note: I'm truly asking a question, I know very little about the subject.

<comment><USER18> Honestly, I'm repeating this question for years. I still didn't come-up with a good answer.

The best that I got is that those criminals rely on living in countries with weak rule of law, and Bitcoin makes for just enough obfuscation that those countries won't investigate them, while countries wiling to investigate don't want to disclaim they have the ability.

Besides, anonymity is not the only feature of Bitcoin useful for criminals. There's also the fact that transactions can not be stopped or undone. Those may be even more important.

</comment></comment></comment><comment><USER19> Considering nobody has had their files decrypted yet, I'm almost surprised how high this figure is. You'd think some people would do at least a bit of research before throwing $300 down the drain.

<comment><USER4> That's not true. The process to send out the decryption key is apparently manual and slow, and some people haven't received keys [https://twitter.com/MalwareTechBlog/status/86418145375993856...](https://twitter.com/MalwareTechBlog/status/864181453759938563) but some have. [https://twitter.com/mikko/status/864107673146490880](https://twitter.com/mikko/status/864107673146490880)

<comment><USER19> Thanks, unfortunately it's too late to edit my comment now.

</comment></comment></comment><comment><USER20> Did they actually decrypted the files after getting money from victims?

It would be interesting, if some white-hat security researcher, pays the $300 money and gets the solution (reverse engineering) . Make its available for free to everyone :)

<comment><USER21> Crypto doesn't work like that.

<comment><USER22> It depends on the implementation. Even so, it's always easier for the authors to patch the malware than it is for researchers to reverse it.

</comment></comment></comment><comment><USER23> Really good technical analysis of WannaCry for hackers (in a good sense): [https://www.youtube.com/watch?v=d_j8UUQbJsc](https://www.youtube.com/watch?v=d_j8UUQbJsc)

</comment><comment><USER24> Article is a couple of days old now. If you do the math right as im writing this it'd be 33.8 bitcoins. at $1721 per coin the total is over $58,000. All points Krebs mentions are still valid however.

</comment><comment><USER25> We really should make it illegal to pay ransom. The only ultimate solution to this problem is to eliminate the incentive.

<comment> matt-attack Ah yes, the old: "This action harms no one but yourself, but we wish to protect you from yourself, so the solution is to turn you into a criminal when you perform said action. For your own good of course."

<comment><USER26> _This action harms no one but yourself_

Paying a ransom is the opposite of this. The action only helps yourself, but harms everyone else, but providing funds to the ransomer.

<comment><USER27> > Paying a ransom is the opposite of this. The action only helps yourself, but > harms everyone else, but providing funds to the ransomer.

Reminds me of my relationship with the people who call themselves the taxing authorities.

</comment></comment></comment></comment><comment><USER28> It's because they asked for $300 when they could've asked for $30,000, considering they infected a lot of large organizations.

<comment><USER29> $300 per machine, not per network.</comment></comment>


18-year-old asks man for advice on her startup, he texts back sleazy messages - <AUTHOR> http://mashable.com/2017/08/15/lydia-jones-tech-harassment/#9rlIsv.NckqX <comment><USER2> Seems like a tough problem (if you consider it a problem). The unfortunate reality of a power-imbalance is that those who are giving out their expertise expect something in return (ROI, promotion, attention/validation, sex).

I don't think what this guy did was even slightly morally wrong, but I would say it sounds unprofessional trying to milk your social status and social capital for physical affection.

But then again, so is hopping to the press because you found 1 sleazy man out there and trying to milk the cultural moment for a few views. (not that one cancels the other)

<comment><USER3> Exploiting a power imbalance to get sex is in fact morally wrong.

<comment><USER4> Is exploiting a sex imbalance to get power morally wrong? Yet women do this all the time, and there are no laws against it, in fact in some ways our culture celebrates it.

I think you have to be very very careful when you start labelling things as moral or otherwise.

<comment><USER3> >Is exploiting a sex imbalance to get power morally wrong?

Not to nearly the same extent, no. If someone has power over you and you refuse them sex, they could potentially do you all kinds of harm. If someone is very sexually attractive but has no power over you, then the worst that they can do is leave you a bit sexually frustrated.

In other words, being offered sex with strings by an attractive person is hardly as bad as being threatened by a powerful person.

>I think you have to be very very careful when you start labelling things as moral or otherwise.

Behavior that is clearly wrong is clearly wrong. The danger lies in not calling it out and allowing it to become normalized.

<comment><USER4> Ah but come now, sexual attractiveness is a form of power! And in fact one of the greatest; men will fight and die for sex with women they desire.

On the question of morality I stick to my guns: I think we are all tempted from time to time to ascend to our high horse and start declaiming of our righteousness, but my question to you would be: are you really so pure of morals that there are none that might find fault with you, given the chance?

I'm also struck by the stridency of some of the statements I'm reading on HN. I wonder if this is a cultural thing as to my British ears they sound almost comically absolutist. Perhaps in Europe this kind of forceful speech is less fashionable?

<comment><USER3> >Ah but come now, sexual attractiveness is a form of power!

Sure, in a sense. But as I said previously, your sexual attractiveness to a person is not something that you can use to threaten them or ruin their life. On the one hand, you have situations where an attractive woman tries to get what she wants by offering sex. On the other, you have situations where a powerful man threatens a woman who refuses his sexual advances. You only have to think of it from a first-person perspective. Would you rather be coerced into sex, or offered sex in return for a favor?

>to my British ears they sound almost comically absolutist.

I am also British.

<comment><USER4> In a sense?! Sexual power can be used to bring someone to their knees; to control, to humiliate; I think you do women a disservice if you diminish this fact, and what's more - and in the spirit of bombast - you are arguing against one of the timeless truths of human existence, and a theme that pervades human culture since time immemorial.

<comment><USER3> You can't control or humiliate someone merely by offering them sex. They can just say "no thanks". If they end up getting controlled and humiliated, it's because they were foolish enough not to do that.

If you are someone's boss, you can control and humiliate them by, say, having them fired. You can't say "no thanks" if your boss fires you.

That is the distinction that I was drawing.

<comment><USER4> You certainly can control someone by offering them sex - it's a well understood and successful tool used in espionage.

<comment><USER5> Espionage is a human science and has developed applied human sciences above and beyond what popular American culture has the maturity and insight to comprehend.

Much of this information, if released publicly, would be dismissed out-of-hand as incorrect to anyone who is an upright and decent person.

To the poster below me, the offer of sex can be used as control regardless of acceptance. If a wealthy and attractive person offers you sex, and you are unaware of an ulterior motive, the mere act of offering does factually impact your psychology and changes your cognitive biases. If the changing in these biases is directed, you are being controlled.

I recommend brushing up on your espionage knowledge. This isn't magic, it's intellectual honesty.

<comment><USER3> You have veered quite a long way off the original topic. It's plainly absurd to draw a comparison between the KGB setting a honey trap and a senior man pressuring a junior woman to have sex with him. The two have nothing to do with one another.

>the mere act of offering does factually impact your psychology and changes your cognitive biases.

Everything impacts your psychology and changes your cognitive biases. In that broad sense of the word "control", we are all "controlling" each other every day, no sex required.

<comment><USER4> It's not a comparison, it's a juxtaposition and you are tying yourself in knots trying to avoid admitting the truth. Women DO have greater sexual power than men. Some women DO use sex to control men. Young women definitely have an idea of their power in the sexual marketplace. And the idea that we can just decide to switch lust on and off is ridiculous.

<comment><USER3> >Some women DO use sex to control men.

I did not say that there are no women who use sex to control men. I said that it is not possible to control someone merely by offering them sex. It requires the cooperation of the person who is being offered sex. This is in stark contrast to the kind of power older men often have over younger women.

>And the idea that we can just decide to switch lust on and off is ridiculous.

Who said anything about switching lust off? All you have to do is decline the offer, which is eminently possible.

<comment><USER5> What about the blackmail potential inherent in offering someone sex?

Edit: I can no longer reply due to the thread length, so here is reply to below post:

To say that someone offered you sex, is to inculcate the idea of a sexual relationship with a person which you would otherwise not be associated with in such a context.

<comment><USER3> There isn't any blackmail potential in offering someone sex. You can just say "yes, so and so offered me sex".

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Here's the thing: for men being decent requires effort - especially online where the risk/reward ration of being a douchebag seems so tantalizingly < 1\. That's obviously changing because doing stuff like this outside the confines of dating sites is becoming much riskier. IMO that's a good thing.

I think men will always have to fight the urge to not "go for it" with women they find attractive. In a way, we're kinda hard-wired to do that. That doesn't mean that we can't or shouldn't fight the urge and be decent to women - especially now that women everywhere are speaking up and letting us know how this kind of behavior makes them feel.

Addendum:

The first reactions to my post are pretty negative. I can see why (over- generalization) but on-balance I don't feel like my post is negative. The core message is - be decent. If the volume of women's complaints are a measure, I'd venture to say there are a lot of men out there that struggle to do so. If you're not one of those guys- awesome . But a lot of dudes are and the first step to getting them to treat women well is to vocalize the expectation that they do so and maybe while we're at it, not trying to shame them into decency by pointing out how awesome _you_ are and, by contrast, what horrible human beings they are for having unacceptable feelings.

<comment><USER7> > Here's the thing: for men being decent requires effort

> I think men will always have to fight the urge to not "go for it" with women > they find attractive.

For you, maybe. Not for me, and not for a lot of men. Please don't typical- mind-fallacy the rest of us who _don 't_ need to expend effort to not be a douchebag.

<comment><USER8> Serious post: It's possible you have low testosterone levels. Annual testosterone checks are an important medical precaution for men, as decreased levels can be caused by serious medical conditions.

<comment><USER9> If I'm not a raging douchebag, I might be low on testosterone? I'm sure that's not what you meant, but that's how I'm reading in light of the original comment. Serious question to a serious post: do you have anything more concrete on which to base one's decision to get checked?

</comment></comment></comment></comment><comment><USER10> Business relationships take place within a business context, email, meetings etc where both parties are pretty clear on intent.

She messaged him on Facebook, that's not a professional environment, it's social. He took it as such, his messages weren't inappropriate. Labelling it as 'sexism' is a little much, it's normal human interaction.

<comment><USER11> She messaged him on Facebook after finding him through a Facebook group dedicated to entrepreneurship. If we grant that facebook is a more casual environment, for the sake of argument, his line of questioning should have ended at "are you single"! I don't see how her intent could have been more clear.

<comment><USER12> Furthermore the Facebook platform (lets include Instagram, Whatsapp, etc) has become an "everything" platform for many individuals both young and old. Family, news, everything is on there. In the absence of clear intent the expected behavior should be not to make such drastic assumptions as sexual interest...</comment></comment></comment>