Stories
Slash Boxes
Comments

SoylentNews is people

Log In

Log In

Create Account  |  Retrieve Password


Blame the rich

Posted by khallow on Sunday January 29 2017, @09:56PM (#2212)
13 Comments
Rehash
In the story about Peter Thiel's dual citizenship thing with New Zealand, there was this interesting observation (subject:"That Fucker is Doomsday Prepping"):

Lots of hedge fund managers and silicon valley billionaires have decided they've been fucking up the country so bad that they need to prepare for it all to go to shit. Every time you hear about a rich guy buying property in NZ, its because they are doomsday prepping.

Those assholes ought to be working on the problem of helping to build new institutions to replace those being torn down by the social isolation and paranoia that their creations are inducing. Instead they are running off to the other side of the planet.

For all of the shit he did, Carnegie built 3,000 public libraries. What has Thiel ever done? Create the fucking eye-of-sauron Palantir, try to stake freedom of the press for a personal vendetta, and oh yeah, help president fugazi dishonor the leading symbol of freedom and democracy on the planet.

Fuck that guy.

While it's probably accurate as concerns Thiel's intentions, there is this blaming as well. So what new institutions need to be built? And why do we want rich people doing that, if they're causing so many problems in the first place?

Let's Godwin this argument a little. So let's say you're a Jew and you have all these crazy Nazis in your society howling about how you're causing all these problems. Even if you wholly agree, what sense would it make in sticking around after they get power? The responsible Jew will be treated exactly like the irresponsible one every time there's a problem and someone needs to be blamed. And with a group as incompetent as crazy Nazis, you know there's going to be plenty of problems, real and imagined, needing plenty of scapegoats, unfortunately for the Jews, it's going to be the Jews.

The universal smart move here is to run before the crazies start killing Jews indiscriminately. There's no reason for Jews or society to even care what Nazis claim responsible Jewish behavior is. It's just propaganda spin.

Same goes for the rich. For example, when the crazies took over and created the USSR, they started blaming all their problems on scapegoats like Kulaks, counter-revolutionaries, etc. Anyone who had been even moderately well-off before the revolution was now the enemy and blamed for everything that went wrong. If you were lucky, that just meant a little prison time and permanent pariah status.

Too many people have learned from the past. When the people in power speak of the problems that the rich as a group didn't cause (for example, someone got rich off of the wars of the past couple of decades, but it wasn't every rich person!) and the responsibilities they're sure that they can't shoulder (you need to make a bunch of vaguely defined, but no doubt enormously expensive "new institutions" to fix the problems you didn't cause), then why shouldn't they eye the escape routes?

I think this sort of ruthless, ideological scapegoating is precisely why US politics is so divisive today. It's a bunch of crazy, bad faith actors who are so far out there that a sane person wouldn't want to compromise with them on anything.

What Can Replace Kuro5hin?

Posted by MichaelDavidCrawford on Sunday January 29 2017, @02:04AM (#2211)
4 Comments
Career & Education

Rusty Foster, the site's owner, said the site went down when its entire data center was decommissioned. While he promised to post a read-only archive, it's been a long time. We speculate that he did not have offsite backups.

Kuro5hin provided an outlet for our cynicism; for example I myself am responsible for the meme of "Ignorant Mother Fucker" - "Mother" and "Fucker" being two separate words, as I feel it sounds more obscene that way.

It also published much-longer essays and stories than one sees anywhere else. My own Living with Schizoaffective Disorder, first published there in 2003, is fifty pages in hardcopy form.

The problem I've got is that I'm bored out of my mind. I really like Soylent News, but it would be inappropriate for me to urge my fellow Soylentils to, for example, "Die In A Fire".

I need something more interactive than just reading what others have written. I like to write, I need a venue for my writing. I have my own website but it's not set up for discussion. "K5" provided that.

Mycroft open source AI

Posted by Gaaark on Tuesday January 24 2017, @04:09AM (#2207)
2 Comments
Code

https://mycroft.ai/mycroft-now-available-raspberry-pi-image/

AI for the raspberry pi: think I'll download it and try it!

(Sorry, didn't have time for a proper submission. Done crsppily from tablet).
  Someone can steal this if they want for submission.

The video is interesting
https://mycroft.ai

I Paid The Apple Tax

Posted by MichaelDavidCrawford on Saturday January 21 2017, @10:54PM (#2205)
5 Comments
Career & Education

To be a Mac software consultant without actually owning a Mac has been awkward. I've been able to work recently because my client is lending me their equipment, but not all have been so cool.

I bought the 2.6 GHz Mac Mini for $699. I don't recall all that's in it as I picked it out a while ago. I also bought AppleCare for $99; in my experience, AppleCare is a good deal. Finally I bought a DisplayLink to VGA adapter so I can use it with my ancient crufty monitor.

Ohmerica

Posted by turgid on Saturday January 21 2017, @11:26AM (#2204)
4 Comments
Topics

As we're multiplying, the world's on the brink,
But that's just what the Devil wants you to think,
Don't ever stop shoppin', don't ever give in,
'Cause if we stop shoppin', the terrorists win.

-- The Claypool Lennon Delirium

Domestic Nuclear Shelters

How to Build a Fallout Shelter.

That nice Mr Putin has built many public nuclear shelters in Moscow in recent years.

Patriots who put their own countries first should always be prepared.

The strong are now putting their own countries first. Several countries are now putting themselves first. Obviously, all countries at present are confined to planet Earth. Who will win? What will happen to those who are second and third? Will the patriots be content?

"Racing for power, and all come in last." -- Megadeth.

We all breath the same atmosphere and drink the same water.

Patriots don't need affordable medical care. Only the weak get sick. President Pull-My-Finger is going to see to it that patriots get to keep as much of their own money as possible so that the weak, who drag the country down, are motivated to improve. On this side of the pond, the NHS is getting ready to be sold off cheap to American healthcare corporations when we get our massive trade deal with the USA. TTIP on steroids? The interests of American corporations will trump (see what I did there) our own interests under the law. Michael Gove is a great patriot.

We're also going to be withdrawing from the European Court of Human Rights. Fine, upstanding patriots don't need "Human Rights." Only criminals and deviants need Human Rights. It was a mistake our writing them in the first place.

I'm glad I'm not foreign. Come to think of it, I'm ethnic. I'm Scottish and live in England. Obviously, I can't be a true patriot. This is worrying.

And finally, here's one I made up all by myself:

Hey diddle diddle, Vlad did a piddle,
All over the Whitehouse floor,
The little Trump laughed to see such sport,
And the Brexiters clamored for more.

Christmas is coming, turkeys.

PS. At least patriots have democratically proved that Global Warming is a liberal-fascist Marxist conspiracy to keep the poor down.

PPS. That other great British patriot, Nigel Farage is taking a job with Faux News.

PPPS. UKIP's Eddie Hitler is standing for election to parliament in Stoke Central. Will the great patriots get a second MP?

Thanks for ignoring THAT story

Posted by GreatAuntAnesthesia on Friday January 20 2017, @11:48PM (#2202)
24 Comments
News

I'm not one of those soylentils who complains about politics stories not being techie enough for this site, but nonetheless i'm glad we haven't had a story about Trump's inauguration. I haven't read / watched anything about it and yet somehow I was sick of it before it happened. I guess I'm just weary of the divisive, partisan bitching.

Let's all talk about computers, or robots, or space or something.

RFC: IMAP based Chat App

Posted by q.kontinuum on Thursday January 19 2017, @10:33AM (#2201)
17 Comments
Digital Liberty

Motivation

For some time I'm a bit unhappy with existing instance messenger apps for smartphones. All chat apps like WhatsApp, Signal, Telegram, Threema and similar have a couple of flaws in common. On the other hand, alternatives usually have a hard time to gain relevant market-share. Users will only use it once market-share is already high.

  • Components out of users control
  • Metadata is available to service provider
  • No inter-connectivity with other vendors

The root cause of all of these flaws is centralized infrastructure. To mitigate these issues, we would need a
chat application satisfies following criteria:

  • Use well established protocol
  • Enable users to host their own servers with connectivity to other servers
  • Support end2end encryption
  • Support text-, picture-. audio-, video-messages
  • Voice chat (voip call)
  • Speed (more or less instance message delivery, if possible)/li>

Following features are not required:

  • Online Status
  • "typing" notification
  • read-notification

Concept

Essential features:

  • Messenger uses a standard (existing?) email account, preferably one supporting IMAP
  • Messages are sent as email, plus a predefined tag in header, e.g. "X-IM: true", and an identifier in subject line ("IM:")
  • Mail server is monitored for incoming messages, preferably using push-notifications. Only messages matching the criteria subject="IM:..." are downloaded.
  • Encryption is implemented using existing standards, like PGP. Session keys can be supported once it is established the counterpart uses a messenger as well
  • Existing key-servers for public-keys can be used
  • People are identified by email address
  • voip calls are point2point connections initiated via a message containing the current IP

Optional features:

  • Delete messages from server once downloaded, to prevent cluttering the inbox
  • A dedicated mail-server could be provided to register $INTERNATIONAL_PHONENUMBER@imap-im.org, supporting SMS-verification. (To keep costs down, server could reject any message not having the "X-IM:" tag and "IM:" subject line. It could also delete all messages once they are received by the client. Retention policy could be set.)
  • Whitelisting: For new sender not in phonebook, only one message is accepted and shown in a separate screen. If the user rejects the initial message, the sender is ignored until manually unblocked. If the user accepts the sender, ze's offered to store in address-book
  • Read-notification

Pro/Contra
Pro

  • No centralized infrastructure makes it more challenging to mass-surveillance communication, even meta-data
  • Protocols are well established
  • Virtually everyone has already an email-address. If the recipient doesn't use the messenger, ze should still be able to read the message and reply via favorite email client

Contra

  • Email is conceptually not developed for instance communication, delays are always possible (although usually it is pretty fast)
  • Message overhead (email headers etc.) is enormeous for short messages

Mainly, the idea is to implement a mail-client with a UI looking like an instance messenger, plus some features like an embedded voip-client, parsing of messages to support stickers, etc. Any showstopper I overlooked? What does an instance messanger provide, anyway, that an email-client doesn't? Any additional ideas?

Pressure Cooker, Induction Heater, systemd, PHP and MySQL

Posted by cafebabe on Friday January 13 2017, @08:55AM (#2192)
10 Comments
Hardware

Every year between Christmas and New Year, there is a geek gathering in Germany organized by the Chaos Communications Club. Talks are available on their website and I've taken the opportunity to trawl through the archive. One of the more accessible projects is an ongoing attempt to make a cooking machine which combines weighing scales, slicer, rice cooker, pressure cooker and sous-vide cooker. That's a sensible idea. However, the implementation is barking mad. Version 1 and version 2 are described in a 54 minute talk from 2012. Version 3 and version 4 are described in a 39 minute talk from 2014. I prefer version 2, especially given that a potential investor requested the second prototype then said something akin to "I wished you hadn't shown me this."

I have extreme misgivings about the placement of a Raspberry Pi - a credit card computer with no ECC RAM or other safeguards - in the proximity of heat and magnetic fields. This isn't just a means of bootstrapping. The entire design philosophy is about dangerous kludging and shows neither expertise in hardware or software. Another blown 1.2kV transistor? That was an impressive noise. Control software written in PHP. XML configuration deprecated in favour of MySQL Server. Thankfully, they're not completely mad and strongly discourage (intentional) remote control of the machine. Also, there is consideration for an emergency stop button, as defined in ISO 13850. However, if they want to rank recipes by use then the control systems (running systemd) will be communicating on the public Internet. And I don't have any faith that it'll be achieved securely and competently.

"A watched pot never boils"? Perhaps that'll become "A watched IoT pot never explodes."

Red States

Posted by The Mighty Buzzard on Tuesday January 10 2017, @08:31PM (#2188)
20 Comments
/dev/random

Found a story about my... well not my home town but the town you have to go to from my home town for anything besides gas, beer, or religion. Turns out Nick Cage's rental car broke down there and he had a thing or two to say about the place. See, that's what I mean when I say to folks who only see what my views on politics and other big shat are, you don't know me at all.

This kind of shit is just another day in a red state. If someone comes up and says you owe them something that you don't, you laugh and punch them in the face but if you see someone in actual need, you help your fellow man because it's the right thing to do and because you might need a hand too some time. In a place where most everybody grows up poor and having to work their ass off to get by, you help each other because it's just what you do. Nick could have broke down a half mile from where he did over by the meth dealers and he still would have gotten the same reception.

Setting Sensible Compiler Flags

Posted by cafebabe on Thursday January 05 2017, @05:10AM (#2183)
9 Comments
Code

Compiler flags have become horribly sub-optimal and can be greatly improved for small computers and virtual hosting. The lazy case:-

gcc -O3 foo.cc

should be strictly avoided. Assuming this is run on a computer with 1GB RAM, this is functionally equivalent to setting some of the flags to:-

gcc --param ggc-min-heapsize=131072 --param ggc-min-expand=100 -fno-strict-overflow -fsigned-zeros -fsignaling-nans -ftrapping-math -fdefer-pop -fno-omit-frame-pointer -fno-stack-protector -fearly-inlining -finline-limit=1200 -fno-merge-constants -fgcse-lm -fgcse-sm -fgcse-las -fgcse-after-reload -fira-region=mixed -fsched-spec -fsched-spec-load --param max-hoist-depth=30 --param max-inline-recursive-depth=8 -freorder-blocks -freorder-functions -falign-functions=1 -falign-loops=1 -falign-labels=1 -falign-jumps=1 -ftree-ch -ftree-loop-distribution -ftree-vect-loop-version -fipa-cp-clone -ftracer -fenforce-eh-specs foo.cc

This is probably not what you want. After spending four months or so of intensively compiling code for systems with small RAM and small processor cache, these flag options look grossly inefficient. If you're doing cloudy computing, credit card computing or working on any system with multiple cores then you'll very probably want to specifically set many of these flags to something more like:-

gcc --param ggc-min-heapsize=32768 --param ggc-min-expand=36 -fstrict-overflow -fno-signed-zeros -fno-signaling-nans -fno-trapping-math -fdefer-pop -fomit-frame-pointer -fstack-protector-all -fno-early-inlining -finline-limit=4 -fmerge-constants -fgcse-lm -fgcse-sm -fgcse-las -fgcse-after-reload -fira-region=one -fno-sched-spec -fno-sched-spec-load --param max-hoist-depth=6 --param max-inline-recursive-depth=0 -freorder-blocks -freorder-functions -falign-functions=64 -falign-loops=64 -falign-labels=1 -falign-jumps=1 -fno-tree-ch -fno-tree-loop-distribution -fno-tree-vect-loop-version -fno-ipa-cp-clone -fno-tracer -fno-enforce-eh-specs foo.cc

Depending upon what is being compiled, this can reduced stripped binary size by 1/3 or more. 4/5 has been observed in optimistic cases. Furthermore, this is not at the expense of speed. Execution time for regular expressions can be reduced by 22% and execution time for SQL stored procedures can be reduced by 45%. Compilation time and memory can also be reduced to the point that it is possible to self-host within 512MB RAM. As an example, with the addition of --no-keep-memory --reduce-memory-overheads to minimize compiler state, compilation of clang-3.8.1 using gcc-4.9.2 goes from exhausting a 2GB application space to requiring 360MB RAM.

The philosophy is to squeeze as much code into L1 cache while reducing cache misses. In many contemporary cases, L2 cache and L3 cache doesn't exist or has contention with hundreds of simultaneous users, possibly to the extent that cache affinity cannot be utilized. In such cases, available L3 cache may be smaller and slower than L1 cache.

Anyhow, let's pick off some quick wins. gcc and clang have multiple register allocation strategies. gcc's default is a nice conservative choice which compiles legacy code without being pathological. Unfortunately, for contemporary systems, this is a completely borked setting but it can be easily rectified with -fira-region=one. A setting which notably reduces compilation time is --param max-hoist-depth=6. I am under the impression that this setting reduces the bound for moving stuff out of loops. Why would we reduce this? It is, unfortunately, an O(n^2) process and code has to be seriously awful to require more than six hoists. A pathological case would be useless code inside nested XYZ loops. If you're compiling that then your program deserves to run slowly. Anyhow, reducing this bound makes a difference to compilation time without significantly affecting output. In combination with -fno-early-inlining, -fno-tree-vect-loop-version, -fno-ipa-cp-clone and -fno-tracer, program footprint can be reduced to the extent that compilation and execution time outweighs any disadvantage.

Perhaps some of these flags should be explained in more detail. Compilers typically perform a number of transforms on a program. Some of these transforms may be performed multiple times. A transform may be scheduled two or more times in a row or a transform may be repeated after many other transforms are applied. One of these transforms is inlining. In this case, it is typical to place the code of small subroutines directly in the place where they called. This saves a call and return. It also allows each inlined instance to be optimized into the surrounding code. For example, if each invocation uses a different constant, inlined copies may be optimized accordingly. -fno-early-inlining cuts out a transform which bloats compiler memory usage, compiler execution time, compiled program size and (unless you have exclusive use of a fat L3 cache) binary execution speed. Early inlining is a great optimization for a desktop application but it is a hinderance for almost every other case.

Another transform is loop unrolling. In the trivial case, a loop which iterates a fixed number of times can be re-written by a compiler. The content of the loop is duplicated a fixed number of times. This eliminates comparisons and branches. It also eliminates use of a loop register. Therefore, the contents of the loop (and functions called (or inlined)) have more registers available. Unless the number of iterations is high, this is a great optimization for processors with no instruction cache or very large caches. It is, however, counter-productive for systems with small caches or very high cache contention. In addition to unrolling there is vectorization. In this case, a compiler will attempt to perform pipelining and/or use SIMD instructions. Where it is not possible to determine alignment of vectorization at compilation time, gcc emits aligned and unaligned versions plus conditional code. This bloat can be inhibited with -fno-tree-vect-loop-version. And modification to the entry point of a partially rolled loop can be inhibited with -fno-tree-loop-distribution.

-fno-ipa-cp-clone inhibits currying. Currying is highly encouraged for interpreted languages. However, for a native binary running through a processor with a tiny instruction cache, it is a hindrance. With -O3 compilation, the default is to make multiple copies of functions which are deemed too large to inline and perform optimizations on each copy anyhow. This is inhibited with -fno-ipa-cp-clone. Admittedly, where functions are not curried, a processor performs extra work. However, it is assumed that clock cycles taken to perform extra work are less than clock cycles wasted by instruction cache misses and/or virtual memory paging. In practice, currying is useful for compilation of desktop applications and dedicated server applications but not useful elsewhere.

-ftracer is another source of bloat and interacts particularly badly with C++ templates. In this case, a compiler provides a separate function exit point for every conditional code path. The mass elimination of dimers allows a very large amount of flexibility with optimizations. However, this occurs at the expense of significant bloat. Such bloat is likely to be counter-productive away from a desktop environment. You may wish to apply -fno-tracer (and -fno-ipa-cp-clone) selectively. For example, on a mixed C/C++ project, such as MySQL Server, -fno-tracer (and -fno-ipa-cp-clone) works well when only applied to the C++.

--param max-inline-recursive-depth=0 inhibits unrolling of recursive functions. The recursive version of loop unrolling probably works really well on a Xeon but, on armv6t, it blows goats.

-fgcse-lm -fgcse-sm -fgcse-las -fgcse-after-reload prevents particularly boneheaded sequences of instructions occurring even when -O3 is replaced with -O0 or -Os. (We have a script with this functionality. This allows self-hosted compilation of MySQL Server 5.7.15, clang-3.8.1 and suchlike within 256MB RAM.) Similarly, -fdefer-pop redundantly retains a useful speed and size optimization when other optimizations degrade. For your purposes, it is very probable that these flags can be omitted without adverse effect.

-fno-signed-zeros allows additional float optimizations by assuming that IEEE754 +0.0 is equivalent to IEEE754 -0.0. -fno-signaling-nans -fno-trapping-math reduces bloat by eliminating divide by zero checks and suchlike which your interpreter, database or whatever should handle anyhow with application-specific code. -fstrict-overflow is badly named but enables additional integer optimizations on the assumption that undefined integer behavoir is not exploited. In practice, stuff like incrementing the largest integer still leads to undefined behaviour such as integer wrap-around.

It should be noted that -fstrict-overflow -fno-signed-zeros -fno-signaling-nans -fno-trapping-math -fmerge-constants -fno-enforce-eh-specs is strictly against C and C++ specifications. In practice, tolerant code and debug builds catch most of the problems. One exception is that python tests note the non-conformance of integer and float mathematics. Whereas, perl incurs no such problems and obtains faster execution speed. Whatever.

-fno-sched-spec -fno-sched-spec-load inhibits some shocking behaviour. Assuming a large cache and an advanced processor, there exist cases where it is beneficial to fetch data before a branch occurs. This remains beneficial even when one of the two code paths doesn't use the fetched data. What actually occurs on a processor with out-of-order execution is that a request to load a register occurs, a decision to perform a branch occurs, then a code path may use the data. In this case, data may be obtained partially or fully in the period taken a branch and subsequent instructions. That's the ideal case. On a simpler processor or a heavily loaded server, a costly and unnecessary cache miss is likely.

Parameters with magic numbers may not be optimal. These numbers are based on random walks and exponential decays - but tweaked for pragmatic reasons. I'd like to perform A/B testing to get empirical improvements.

-falign-functions=64 -falign-loops=64 -falign-labels=1 -falign-jumps=1 greatly improves execution speed on ARM6. Unfortunately, it bulks binaries by about 5% and this cost is potentially pushed to virtual memory. However, where RAM is sufficient, these parameters minimize cache line usage. Some ARM processors only have 128 cache lines. This can be maximized by aligning functions and loops to cache line boundaries. A worked example follows. An 80 byte loop without alignment may be placed across three cache lines. For example, 4 bytes at the end of one cache line, 64 bytes fully occupying one cache line and 12 bytes at the beginning of another cache line. This arrangement unnecessarily increases cache contention. If the loop is always placed at the start of a cache line, the total number of cache lines can be minimized. Technically, all four parameters can be set to 64 but this would bulk programs by another 5% while providing minimal gains. Conceptually, only back branches require alignment. So, subroutines, for and while are aligned. if, else, break, try and catch are unaligned. Consider the case of else inside a for loop. Both halfs of the condition will eventually be cached and therefore the total length of the loop is more important than alignment of its constituent parts. Indeed, for nested loops, I wish that it was possible to only align the outermost loop.

Inspiration for cache alignment comes from an explanation of the Dalvik virtual machine interpreter. In this case, Java bytecode re-compiled into Dalvik bytecode may run faster on an ARM processor even when not using Jazelle hardware acceleration. The trick hinges on one instruction: a jump indirect with six bit pre-scale. This is placed at the end of one cache line. This allows interpreter code for each trivial Dalvik instruction to fit within one cache line. In practice, relatively few cache lines are required to implement common Dalvik instructions. This makes a bytecode interpreter practical even on processors with 128 cache lines. Overall, this arrangement degrades gracefully and incurs less cache contention than Jazelle's partial hardware implementation of Java.

64 byte alignment will also work on x86. However, Intel instruction dispatch circuitry typically works on 16 byte chunks (with or without alignment). Therefore, smaller alignment or no alignment may be optimal on x86. However, if you want to set and forget one lot of flags, the suggested ones are likely to be an overall gain across multiple processor architectures.