The "high-level CPU" challenge (2008) - <AUTHOR> http://yosefk.com/blog/the-high-level-cpu-challenge.html <comment><USER4> Author here. I think today that apart from making my case in a bit of an obnoxious tone, I also somewhat overstated it: while it's true that many "high-level" constructs do have a cost that will not magically go away due to any logic built into hardware, at least not fully, it is also ought to be true that a lot can be done in hardware to make software's life easier given a particular HLL programming model, and I'm hardly an expert on this. My true interests are in accelerator development so starting at the GPU and further away from the CPU and so lower level and gnarlier than C in terms of programming model.

I will however say that the Reduceron and in general the idea of doing FP in hardware in the most direct way are a terrible waste of resources and I'm pretty sure it loses to a good compiler targeting a von Neumann machine on overall efficiency.

The way to go is not make a hardware interpeter, that is no better than a processor with a for loop instruction added to better support C. The trick is to carefully partition sw and hw responsibilities as in the model to which C+Unix/RISC+MMU converged to.

<comment><USER5> Actor-based dynamic language author here. (Doesn't matter which one; I think I speak for all of us.) Thank you for being honest with us; we are not a very performance-oriented group sometimes.

We're generally in favor of things which accelerate message passing between shared-nothing concurrent actors. Hardware mailboxes or transactional memory are nifty. OS-supported message queues are nifty; can those be lowered to hardware in a useful way?

<comment><USER6> Well, I never thought I'd be plugging my PhD research here, but:

"Asynchronous Remote Stores for Inter-Core Communication" [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.592...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.592.1178&rep=rep1&type=pdf)

To my knowledge, this is still the only hardware-assisted message passing scheme that is virtualisable (ie compatible with a "real" OS like Linux).

Hardware mailboxes are great, but time-sharing OSs can't deal with finite hardware resources that can't be swapped out easily. Software-based queues die a fiery death thanks to cache coherency - reading something that another core just wrote will block you for hundreds of cycles.

<comment><USER4> Virtualizable hardware-assisted message passing is awesome. (MIPS for instance had a big fat ISA extension for hardware-assisted message passing and cheap hardware multithreading which Linux couldn't use and they then threw out the window exactly when they introduced hardware virtualization of the entire set of processor resources.)

As to software-based queues dying a fiery death - in what scenarios? As I said in a sister comment, I (think that I) know that things work out in computational parallelism scenarios where many tasks are mapped onto a thread pool, TBB-style, that is, I don't think the hardware overhead is ridiculously large in these systems. Where do things go badly? 100K lightweight threads communicating via channels, Go-style?

<comment><USER6> Whoa - MIPS virtualised their message passing hardware? How?!

Software-based queues die a fiery death when the latency of a send/receive is critical, because you end up stalling on a really slow cache-coherence operation. So, for example, anything like a cross-thread RPC call takes ages (you wait for the transmission and wait for a response, so it's much slower than a function call and often a system call - the Barrelfish research OS suffers a bunch from this). There are also algorithms you just can't parallelise because you can't split them into large chunks, and if you split them into small chunks the cost of communicating so frequently destroys your performance. (Eg there was a brave attempt to parallelise the inner loop of bzip2 - which resists coarse parallelisation thanks to loop-carried dependencies - this way).

Software based queues perform just fine on throughput, though - if you're asynchronous enough to let a few messages build up in your message queue, you'll only pay the latency penalty once per cache line when you drain it (and with a good prefetcher, even less than that).

The examples you cite are actually both instances of software cunningly working within the limits of slow inter-core communication. Work-queue algorithms typically keep local, per-core queues and only rebalance tasks between cores ("work stealing") infrequently, so as to offset how expensive that operation is. Lightweight threads with blocking messages (like Go or Occam or some microkernels) work by turning most message sends into context switches within one core - when you send a message on a Go channel, you can just jump right into the code that receives it. Again, they can then rebalance infrequently. (For an extra bonus, by making it easy to create 100k "threads", they hope to engage in latency-hiding for individual threads - and once you're in "throughput" mode it's all gravy).

<comment><USER4> > Whoa - MIPS virtualised their message passing hardware? How?!

No, I meant to say that they simply obsoleted that part of their architecture when they added virtualization, because they couldn't virtualize it.

> Eg there was a brave attempt to parallelise the inner loop of bzip2 - <USER2> > resists coarse parallelisation thanks to loop-carried dependencies - <USER3> > way.

So you say you can do hardware-assisted message passing that can be virtualized and can speed up bzip2 by parallelizing? How few instructions per RPC call does it take for you to still be efficient vs today's software-based messaging? (This is getting fairly interesting and it should be particularly interesting to serious CPU vendors.)

<comment><USER6> This is getting deep in an ageing thread - do you want to take this to email? (It's in my profile)

Pipelined bzip2 wasn't in the evaluation for my research, but I bet remote stores would get considerably better results than software queues. Parallelising one algorithm is something of a stunt, and gets you just a single data point. Instead, I did a bunch of different benchmarks (microbenchmarks for FIFO queues and synchronisation barriers; larger benchmarks including a parallel profiler and a variable-granularity MapReduce to measure how far remote stores could move the break-even point for communication vs computation; and an oddball parallel STM system that I'd previously demonstrated on dedicated (FPGA) hardware). I got around an order of magnitude on all of them (some a little less, some much more).

The writeup starts on page 59 of [https://www.cl.cam.ac.uk/techreports/UCAM- CL-TR-831.pdf](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-831.pdf) and the evaluation on page 65.

Looking back, I seriously regret not taking more time to sit down and write it up more clearly, because I do think this should be interesting to serious CPU vendors. However, by that point I had reached the point of "I'm fed up with this PhD; I'm going home now". As I knew I didn't want to stay in academia, I published in a mediocre venue rather than revising for a better one, and went off to Silicon Valley instead. Your comments have made me re-read my old work, and it's painful to wonder how much further it could have gone if I had explained it better.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The history of "higher level" instructions isn't good. The DEC VAX had an assembly language intended to make life easier for assembly programmers, but it slowed the machine down. The Intel IAPX 432 had lots of bells and whistles, but was really slow. The RISC machines with lots of registers turned out not to be all that useful, and too much register saving and restoring was required. RISC is a win until you want to go superscalar and have more than one instruction per clock. Then it's a lose. Stack machines that run some RPN form like Forth or Java code have been built, but don't go superscalar well.

A useful near-term feature would be zero-cost hardware exceptions on integer overflow. This is an error in both Java and Rust, and tends to be turned off at compile time because it has a performance penalty. The problem is that people will want to be able to unwind and recover, which means exact exceptions and a lot of compiler support for them.

If you could figure out how to do zero-cost subscript checking, that would be a step forward. That check needs additional info about bounds, which usually means a delay.

I used to be a fan of schemes for safely calling from one address space to another. i386 almost has this, with call gates, which don't quite do enough to be useful. A few machines have had hardware context switching, but that hasn't been a big performance improvement. All that has to be tightly integrated with the OS or it's a lose. It's an enhancement to Plan 9, not anything anybody uses.

The same is true of fancy schemes for inter-CPU communication, but that probably needs more attention. Like it or not, we have to figure out what to do with large numbers of non-shared-memory CPUs. Some way to set up memory- safe message passing between non-shared-memory CPUs without involving the OS after setup would be useful.

An IOMMU that allows drivers in user space with minimal performance degradation is a good thing. Those exist.

<comment><USER8> > _Stack machines that run some RPN form like Forth or Java code have been > built, but don 't go superscalar well._

I've been interested in Forth (and related stack) processors for a while, and my armchair observations over a few months have suggested that the (much- vaunted) performance gains associated with such processor designs are apparently not straightforward to map or relate to or take advantage of.

I remember (unfortunately not sure where right now) reading how the GA144 was built at a time when 18-bit memory was the current trending novelty and that it's not really a perfect processor design. I'm still fascinated by it though (sore lack of on-chip memory notwithstanding).

What sort of scale are you referring to when you say "superscalar"? 144 processors? 1000? Do stack-based architectures remain a not-especially- practical-or-competitive novelty, or are they worth pursuing outside of CompSci?

(FWIW, everything else you've written is equally interesting, but slightly over my current experience level)

<comment><USER7> Pure Forth machines were interesting when the CPU clock and the memory ran at about the same speed, and the number of gates was very limited. Chuck Moore's original Forth machine had a main memory, a data stack memory, and a return stack memory, each of which was cycled on each clock. It took only about 4K gates to make a CPU that way.

Today, the speed ratio between CPU and main memory is several orders of magnitude. The main problem in CPU design today is dealing with that huge mismatch. That's why there are so many levels of cache now, and vast amounts of cleverness and complexity to try to make memory accesses fewer, but wider.

The next step is massive parallelism. GPUs are today's best examples. Dedicated deep learning chips should be available soon, if they're not already. That problem can be implemented as a small inner loop made massively parallel.

<comment><USER9> > the speed ratio between CPU and main memory is several orders of magnitude

What if you compare scratchpad SRAM and an energy-efficient CPU?

<comment><USER10> Compare in what way? e.g. the L1 cache is SRAM running at core speed with low latency (4 cycles for Haswell).

<comment><USER9> A factor of 4 instead of orders of magnitude means a Forth machine might still be worthwhile. No?

<comment><USER10> Where's the Forth machine getting its operands from?

Sure, if you constrain your programs to use a tiny area of memory you might be able to achieve theoretical speed, but what workloads can you achieve with that?

If you were to write a browser in Forth, presumably it would still have to store all its DOM in DRAM?

<comment><USER9> You probably want to parallelize the browser for energy efficiency. Then you can distributed the DOM across the scratchpads of hundreds of cores maybe?

<comment><USER10> So each core has its own JS engine, or when you iterate across the DOM with a selector you have to query across all the nodes? This doesn't sound great.

(The "pile of cores with scratchpads" exists e.g. Tilera and Netronome, and they're a right pain to program for)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Some assorted ideas:

* Expose the data dependency graph directly to the processor, rather than forcing the processor to infer it from the instructions.

* Annotate when data is read-only, to reduce communication between cores (for the sake of avoiding latency, not for bandwidth savings).

* Add a mechanism for much cheaper (if more limited) parallelism where a single core would work on multiple, related thunks in parallel, even if those units of work would be far too small to be worth coordinating with another thread to offload. This would likely be largely implicit, taking advantage of the first feature.

* Instructions for graph traversal. The CPU could (for some uses) order the traversal in a way that improves cache locality, based on how the graph is actually laid out in memory (and prefetch uncached nodes while working on cached ones).

* Something like map & reduce, where you can apply a small (pure) function to a list of data. Again, this would likely be done in parallel.

<comment><USER9> > data dependency graph directly to the processor

What format would you propose? How is it different to instructions?

> Annotate when data is read-only

What overhead would you save? On the cache coherence protocol level?

> a single core would work on multiple, related thunks in parallel

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

> instructions for graph traversal

Your Intel CPU can already do prefetching. Others have special instructions for it. Hyperthreading does the "work on cached stuff first" part.

> like map & reduce

Use the GPU.

<comment><USER12> Answering with my own take on the subject.

> What format would you propose? How is it different to instructions? It would > still be instructions, but either by reworking what their operands are and > introducing a destination (instruction address + operand port). Another > option that could maybe work is a second and mirroring instruction stream > that contains only the dataflow/dependencies.

> What overhead would you save? On the cache coherence protocol level? Current > strategy is write-invalidate, I believe. In some heavy-contention situations > (e.g. lots of spin-loops on one variable), using a 'write-once' instruction > would traffic. Thinking more radically: With an overhaul of the entire > virtual-memory system, a write-once instruction becomes potentially very > interesting (Jack Dennis had an interesting paper on the subject: > [http://www.cs.ucy.ac.cy/dfmworkshop/wp- > content/uploads/2014/...](http://www.cs.ucy.ac.cy/dfmworkshop/wp- > content/uploads/2014/08/DFM2014-9-On-the-Feasibility-of-a-Codelet-Based- > Multi-core-Operating-System.pdf)).

> VLIW Only if you mean something like Mill > ([https://en.wikipedia.org/wiki/Mill_architecture](https://en.wikipedia.org/wiki/Mill_architecture)), > instead of Itanium.

</comment></comment></comment><comment><USER13> 1\. Eliminate cache coherency protocols (replacing it with cache manipulation/inter-CPU communication instructions)

2\. Eliminate virtual memory (replacing it with nothing)

I'm not a CPU designer, but my understanding is that removing features allows for a denser/faster CPU. Well, these are two features that a suitably high- level language has no need for, because a high-level language doesn't expose "memory" to the programmer.

Edit: Though, I 100% agree with what I believe is the core point of the author. We should not implement high-level features in hardware. In fact we should implement as little as possible in hardware, moving as much as possible into software. If Intel would let third parties generate microcode for their CPUs, we could move a lot further in that direction...

<comment><USER14> Boy, do I have a new processor architecture for you. For the past 3 years my company (REX Computing), has been working on a new architecture that not only covers both of your points, but removes hardware managed caching entirely and replaces it with software managed (physically addressed) scratchpad memory. By removing all of the unnecessary logic (MMU, TLB, everything required for virtual addressing, prefetching, coherency, etc) associated with the onchip memory system, we can fit more memory on the chip itself, have lower latency to that memory, and use a lot less power. As we fully expose the memory system to our software tools, we can make very good decisions at compile time that replicate most of the features you get in having a hardware managed caching system.

We have silicon back, and are now working with early customers in showing a 10 to 25x energy efficiency improvement for high performance workloads.

I gave a talk at Stanford last week that covers the hardware architecture and shows off our development hardware: [https://www.youtube.com/watch?v=ki6jVXZM2XU](https://www.youtube.com/watch?v=ki6jVXZM2XU)

<comment><USER8> Wow. (Not op)

Definitely watching the video later when I have time. Thoughts from my initial impression:

1\. Please put benchmarks up on HN when you can :)

2\. Would be awesome if you could get this into the hands of low level kernel developers who can tinker with this and see what Linux is like on it - if it's capable of doing that much? (Need to watch the video!)

3\. Conservativism FTW (IMO) when thinking about offers [that come in after you've done (1) :P]

<comment><USER14> 1: Around the 30:40 mark in the video I transition to the live hardware demo, where I learned to never do live demos. While it did not work there in person, I do show pictures from it working earlier in the day along with the results from our 1024-point in place FFT assembly test. It was written and tested Monday and Tuesday of last week (finished the night before the presentation), so it is not fully optimized, but we are getting a very good 25 double precision GFLOPs/watt. As a comparison, Intel and NVIDIA's advertised FP64 numbers are around 8 to 12 GFLOPs/watt while they are on a more advanced process node (They are on 14/16nm, while our test silicon was on 28nm).

We're in the process of getting cross platform benchmarks (HPL, HPCG, FFTW, Coremark, etc) up and running, but I'm hoping we'll be posting results shortly.

2\. Since Linux 4.2, there has been a mainline port for STM32 which does not have a MMU, so porting linux is technically possible, though not on our priority list. Something like uCLinux would probably be easier, but not as useful. I have no doubt our cores would be able to handle it, it is just that our current customers already expect their software to be running on bare metal.

<comment><USER15> I didn't watch the talk in full, so forgive me if you addressed this somewhere in the Q&A: What are the differences between your architecture and the Epiphany chips? As far as I can tell they have approximately the same amount of local scratch pad memory and also a 2D mesh routing infrastructure and general overall design philosophy, one major difference seems to be the Serdes design that you have.

Edit: Ah ok, one major difference seems to be that you have quad-issue VLIW as opposed to RISC and apparently you are 10x faster than Epiphany, that is _really_ impressive.

<comment><USER14> On your edit: RISC and VLIW are not mutually exclusive. I would say we are a RISC architecture (Load/store based/everything happens on registers, fixed instruction word size, shallow pipeline) that happens to have a much simpler instruction decoder & higher instruction level parallelism since our compiler guarantees that the instruction bundle (the 64 bit Very Long Instruction Word containing 4 "syllables" of instructions itself) will only give instructions that will not conflict with anything it is given with or in the pipeline.

Other than we are faster (20% higher clock plus 2x higher IPC) and more efficient (Epiphany is single precision only, where we are twice as efficient as them, we also support FP64), there are three quick points:

1\. We actually have double the local scratchpad of Epiphany per core, and our SPM banking and register port scheme actually enables us to operate all four functional units within a core simultaneously, while also having data go in and out of the core on the Network on Chip. With Epiphany, you are very limited in what instructions can run together primarily due to port conflicts... the biggest difficulty is that you can't do any sort of control instructions with anything else.

2\. As far as the Network on Chip goes, we are able to guarantee all latencies through a strict deterministic static priority routing scheme. Epiphany had 3 levels of it's Network on Chip, one for stores, one for read requests (8x slower than stores), and one for off chip communications. We have a (patent pending) way of simplifying all of this greatly while reducing latency and having greater bit efficiency.

3\. Off chip memory bandwidth is _extremely_ important to us. Even on our _test_ chip, we have 4x higher bandwidth than the Epiphany IV, plus lower latency... our chip to chip and memory interface also uses the exact same protocol as our NoC, simplifying things even further.

There are a handful of smaller things, though my biggest gripe with Epiphany has always been the lack of bandwidth both on and especially off chip. If you are targeting DSP and similar applications like both Epiphany and we are, you really _really_ need to have the ability to saturate your networks and match compute capabilities with it.

<comment><USER16> How would your Neo ISA compare to the proposed RISC V Cray style vector extension for FFTs?

<comment><USER14> Our current plans are for very simple SIMD modes that reutilize the same hardware to maximize Area and power efficiency. Right now, we can separately load/store the upper half and lower half of a 64 bit register with 32 bits of data, and while we did not have the time to implement it on this silicon, the plan for the future is to have a mode switch to allow the user to use the same set of instructions/hardware/registers to do double, single, or half precision floating point operations.

The other thing we are looking forward to directly test/compare are unums, specifically the new "type 3" ones known as Posits, which are useful (for some definitions of useful) all the way down to 4 bits, and have a greater dynamic range plus greater precision than IEEE floats while using let's bits and theoretically lower area/power on a chip.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Intel did try to introduce a high level CPU in 1981: [https://en.wikipedia.org/wiki/Intel_iAPX_432](https://en.wikipedia.org/wiki/Intel_iAPX_432)

It failed due to very poor performance. There is an excellent paper by Bob Colwell about why the performance turned out the way it did. Prior HN discussion: [https://news.ycombinator.com/item?id=9447097](https://news.ycombinator.com/item?id=9447097)

<comment><USER18> The i960 was a much better attempt. Baseline version had just enough smarts to improve safety or reliability while still overall a fast RISC. Got some customers in embedded.

</comment></comment><comment><USER19> I loved this (paraphrased) quote:

To quote Ken Thompson (from memory) – "Lisp is not a special enough language to warrant a hardware implementation. The PDP-10 is a great Lisp machine. The PDP-11 is a great Lisp machine. I told these guys, you're crazy."

</comment><comment><USER20> This is a good time to mention asynchronous architectures: [https://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchron...](https://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchronous_CPU)

Intel itself [claimed]([http://stackoverflow.com/a/530494](http://stackoverflow.com/a/530494)) that the async CPU performs better than the sync one, but they didn't pursue the project further for lack of large-scale profitability.

</comment><comment><USER21> Well, the Reduceron seems to count as an example. I'm not sure I'm convinced about it's performance, though.

[https://www.cs.york.ac.uk/fp/reduceron/](https://www.cs.york.ac.uk/fp/reduceron/)

That's specialized for just one language, though. In general you can always speed things up, sometimes by quite a bit, if you're willing to make your general purpose computer somewhat less general purpose.

Some of what the Mill folks are doing with hardware assisted stack operations might fall under the category of higher level instructions but those are for C just as much as any other language.

[https://millcomputing.com/](https://millcomputing.com/)

EDIT: Oh, and Linus likes to wax eloquent about the wonders of rep movs and I think he sort of has a point about having good facilities to call routines specific to the hardware, using instructions specific to the hardware that aren't exposed in the public ISA. But again, that's a high level function in hardware but it isn't specific to a high level language and it's mostly about accelerating C.

</comment><comment><USER22> I think yosef misinterpreted JWZ.

In large applications a bump pointer allocator plus generational gc is really fast (yes, stack allocation is fast too, but you can't always do it). A compacting gc avoids arenas, object reuse, or other awfulness. gc enables lock-free / CASed data structures; otherwise memory ownership is too complex to implement (though there's a Rust guy doing really cool stuff [1]). And gc in a threaded program is wildly easier. Unless you liked eg COM-style explicit ref-counting.

As for lisp plus large programs, the large program I worked on did end up with a bespoke (unfortunately) type-free internal language in order to orchestrate itself. Large = low millions of LOC of c++.

[1] [https://aturon.github.io/blog/2015/08/27/epoch/](https://aturon.github.io/blog/2015/08/27/epoch/)

</comment><comment><USER23> The comments following this article (which span a period from 2008 to 2015!) are also very interesting.

<comment><USER24> And interesting comments from 2008 and 2015 here: [https://hn.algolia.com/?query=The%20"high- level%20CPU"%20cha...](https://hn.algolia.com/?query=The%20"high- level%20CPU"%20challenge&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)

</comment></comment><comment> Const-me Great article.

> I have images. I must process those images and find stuff in them. I need to > write a program and control its behavior. You know, the usual edit-run- > debug-swear cycle. What model do you propose to use?

Looks like you need a GPU, not a CPU. Much image processing stuff (and also much neural network stuff) is very suitable for the programming models of modern GPUs. For a first prototype buy an nVidia GPU and use CUDA. That will unlikely work for embedded stuff but if it'll work OK on your PC with CUDA, there's almost 100% chance you'll be able to do that in OpenCL/DirectCompute/whatever.

</comment><comment><USER25> I admit I'm not too well versed in hardware tech. One thing that comes to mind is using associative memory to implement objects, namespaces, etc. (e.g. [http://www.vpri.org/pdf/tr2011003_abmdb.pdf](http://www.vpri.org/pdf/tr2011003_abmdb.pdf) ); although that general approach seems to be mentioned in the comments.

</comment><comment><USER26> The article doesn't seem to consider the SOAR & SPARC family of RISC CPUs, they had instructions to do arithmetic on tagged integers and trap if the tags were incorrect. The feature has been dropped from 64-bit SPARC though.

</comment><comment><USER27> Wait - Pure functional languages making lots of copies and lacking side effects is supposed to be a bad thing from a hardware perspective? As I understand it, synchronising shared memory is a massive source of complexity and stalls in modern processors. You get better performance in multithreaded code when you churn through new memory rather than mutate what you've already got, and even better in a stream processor where you know that is what is going to happen. Still, I suppose that's not a great argument for custom hardware because code that would benefit could most likely be shoehorned onto a GPU. Or maybe that's an argument that GPUs are already pretty close to being the custom hardware that we need.

<comment><USER9> > synchronising shared memory is a massive source of complexity and stalls in > modern processors

Correct.

> making lots of copies is supposed to be a bad thing from a hardware > perspective

Yes, because memory accesses are costly. You want your data to be packed tightly in memory instead of chasing pointers all the time. An array is more efficient than a linked list mostly due to caches.

The balance is key. You want one copy per core, but not one copy per data update.

</comment></comment><comment><USER5> I would love to know whether alternatives to floating-point, such as unums or quote notation, are worth considering for those languages which have rationals in their numeric towers.

<comment><USER14> Well unums in particular (especially the new type 3 "posits" ones) are very interesting and practical for hardware implementation. John Gustafson, the creator of unums, gave the first talk on type 3 unums at Stanford earlier this month, and there are already multiple hardware implementation efforts (one of which I am indirectly overseeing). While many people have recently hyped up low precision floating point for things like machine learning, Posits provide greater dynamic range AND greater accuracy for very few bits (as low as four, but with good ML starting 8 to 10 bits). On top of all of that, it costs less area and power in silicon than IEEE hardware.

Check out the talk: [https://www.youtube.com/watch?v=aP0Y1uAA-2Y](https://www.youtube.com/watch?v=aP0Y1uAA-2Y)

</comment></comment><comment><USER28> The author is stuck on building a better horse.

Not to beat this analogy dead, but the reason Alan Kay et al. are so quick to discuss alternative computing methods should be quite obvious to anyone who doesn't limit their worldview to concepts that humans are already using.

Right now most processors are ridiculously general. They take a handful (ok, a couple thousand or so) instructions and they do their best to parallelize the instructions both on a single loop (core) and multiple cores. These instructions are of the "add, multiple, load, store" variety, with a few additional instructions for machine learning[1] and whatever HP wants[2].

This is it. This is the state of computing. How do bees work? Why can spiders hunt? When did crows start using tools? What makes us different than bonobos? How are all of these creatures so capable, yet so energy efficient?

We are taking a single solution, RISC/CISC architecture, and brute-forcing the hell out of it. Rather than build adaptive or purpose-built hardware, we're stuck on this concept of compile everything to x86/ARM and shrink the transistors (or try and offload parallel number crunching to the GPU).

What the author fails to realize is that computers are just fancy looping mechanisms. We use "HLLs" to compile abstract loops into instructions that run on general purpose machines. That's it.

The "apparently credible" people see the world in this light. They understand that the solution we've chosen is subpar, but the physics will make it work for some time.

A few other commenters have mentioned FPGAs. I'm not here to pitch a future on FPGAs; the die is still flat, the gates can only be reprogrammed so many times and they're generally "expensive."

I will say that we need better tools. FPGAs are a good start. Intel knows this[3]. Microsoft knows this[4].

With an FPGA you can dynamically program the exact logic a given operation will need. Whether it's real-time signal analysis, AI-built logic, or memcached, your logic will run exactly as specified.

Using purpose-built logic to run functions "natively" will drastically improve the efficiency of computation; both in time and energy.

It's really hard to build a horse that will fly to the moon. It's a lot easier to build a spaceship that can carry a horse to the moon.

[1][http://lemire.me/blog/2016/10/14/intel-will-add-deep- learnin...](http://lemire.me/blog/2016/10/14/intel-will-add-deep-learning- instructions-to-its-processors/)

[2][https://en.wikipedia.org/wiki/IA-64](https://en.wikipedia.org/wiki/IA-64)

[3][https://www.bloomberg.com/news/articles/2015-06-01/intel- buy...](https://www.bloomberg.com/news/articles/2015-06-01/intel-buys-altera- for-16-7-billion-as-chip-deals-accelerate)

[4][https://www.wired.com/2016/09/microsoft-bets-future-chip- rep...](https://www.wired.com/2016/09/microsoft-bets-future-chip-reprogram- fly/)

<comment><USER29> I agree and hope VHDL has a more brighter future in FPGA world than Ada did on the mainstream software landscape.

</comment></comment><comment><USER30> If you want a "high-level" computer that can easily run high-level languages you can try building a stack machine. Check out the old LISP machines from the eairly 80s.

High level and fast for the time with some of the most interesting compiler design work.

Some other possible crazy ideas:

       * Write instructions for forcing a read/write of memory into L1 cache

Allow me to tell the CPU to keep a chunk of memory im L1 for the lifetime of my program. I'll save you the transistors for figuring this out on the chip and it'll be easy to implement in a compiler. This is stuff that was done back in the NES and gameboy days (although by hand) with hi and lowmem.

       * Put an easily interfaced FPGA on the die. Get rid of the stupid "one-size-fits-all" vectorization hardware we have today. We can just write our own vectorizations ourselves in the compiler level. Just make a big enough FPGA and we'll do all the math as fast as we want and in the parallelization we want.

This removes a very specific job oriented bit of transistors and allows it to be used for pretty much any problem that's complex enough to warrent attempting to use vectorization. One use of a combination of these ideas is writing an image filtering algorithm. It's a program that loops through the rows of my image, runs the "L1 cache" instruction from earlier, then passes it to my FPGA code which applies some complex filter, then writes it back to memory and continues. With traditional systems you'd be limited to 128 wide segments but I can presumably configure my FPGA segment to read the entire block of cache I want to load into and write back to it all as fast as possible.

This is an extremely hard thing to build but on-die FPGAs would change the face of computing. When they get big enough, who needs GPUs?

       * Make core-shared fully atomic (large) registers for extremely fast but crude IPC

This is how most high level languages operate so I'd imagine this could definetly be made use of.

       * Make the idea of a Core to Core MPI via interrupts and allow them to be configurally "synchronious" (page the program out until handled)

This allows the idea of calling a function on an object running in parallel with "this" object and it will be returned when this function is returned.

These are really crazy ideas. If I had inifnite money, time, and resources I probably couldn't pull something this "out there" off. I think the on-die FPGA is possible but impossible to get right. Most features on a modern processor that take up space are a conbination of functions that could all be done on an FPGA rather then wasting transistors on that _specific_ function.

In a server do I really need 10 million transistors on my CPU for H264 decoding? Replace that with cache and a live-reprogrammable FPGA and we can do that all in software _when_ and _if_ we need it.

<comment><USER31> _> Write instructions for forcing a read/write of memory into L1 cache_

Mightn't optimizing compilers create something of a "crabs in the bucket" syndrome where all the running programs are trying to hog the L1 cache?

<comment><USER30> That should be handled at the OS level and the processor should provide facilities to directly store/page a program into a long term memory. The more the hardware can facilitate the lie that our program is living "forever" in ram the better. I have a feeling that we could also easily just add some memory chips into the computer board to just act as a super fast in-hardware swapfile to wait for things to be paged into memory then into disk.

The L1 cache should be configurable for the entier existance of a program and I'm pretty sure we'd see a lot less paging/pagefaults then.

How far away from your function is $some_global_variable? It doesn't matter if we can force the machine to always keep some_global_variable in cache.

But in short, it would definetly end up being like you say: people skrewing over other people, if there weren't other facilities in place to keep it safe and fast. It's a job for someone smarter then I.

</comment></comment></comment><comment><USER25> The claim that static types (in regards to Haskell) make things low level strikes me as wrong. It's probably a difference in the interpretation of the word "type", which is unfortunately used to describe many different things.

From a C perspective, the word "type" pretty much means "memory layout", e.g. the difference between "char" and "int" is that the latter (may) use more memory than the former; the difference between "int" and "float" is that the bits are interpreted in a different way; a struct describes how to lay out a chunk of memory; and so on. Static checks can be layered on top of this, but it mostly boils down to 'not misinterpreting the bits'. I've seen this concept distinguished by the phrase "value types".

In Haskell land, types have no particular relationship to memory size/layout; e.g. we don't really care what bit pattern will be used to represent something of type "Functor f => (a -> b) -> (forall c. c -> a) -> f b". Unlike C, there's no underlying assumption that "it's all just bits" which we must be careful to interpret consistently; instead, it's all left abstract, grammatical and polymorphic, leaving it up to the compiler to map such concepts to physical hardware however it likes.

I certainly think it's a mistake to think in terms of "high level == dynamic types"; there's the obligatory [https://existentialtype.wordpress.com/2011/03/19/dynamic- lan...](https://existentialtype.wordpress.com/2011/03/19/dynamic-languages- are-static-languages) and I'd also consider Homotopy Type Theory to be a _very_ high-level language. It's also a rather constraining simplification too, as it ignores the many other dimensions of a language.

Haskell's garbage collection is an obvious abstraction over memory which has nothing much to do with static/dynamic types (linear/affine/uniqueness types are very related, but are yet another overloading of "type" ;) ). As another example, I would count Prolog as more high-level than (say) Python since it abstracts over "low level" details like control flow; again, nothing to do with their types. Likewise, a message-passing language, operating transparently over a network would be more high-level than a language which communicates by (say) opening sockets on particular ports of particular IP addresses and serialising/deserialising data across the link when instructed to by the programmer; we'd be abstracting over the ideas of physical machines, locations and networks.

Calling Haskell low level because of its types ignores such other dimensions; in the context of hardware design, machine code, von Neumann architecture, etc. I'd say that abstracting over control-flow with non-strict evaluation is enough to make Haskell high-level.</comment>


Ask HN: What linux desktop tools/apps boosted your productivity? - <AUTHOR> I have switched to Ubuntu 16.04 from MacOS two years ago. Compiz is one of the things helped me manage my workspace and windows which really boosted my productivity. I wonder what other tools I might be missing out.<p>Thank you. <comment><USER2> Emacs org-mode[0]

From the website's description:

Org mode is for keeping notes, maintaining TODO lists, planning projects, and authoring documents with a fast and effective plain-text system.

I just copied some of the set-up from here[1]

[0] - [https://orgmode.org/](https://orgmode.org/)

[1] - [http://doc.norang.ca/org-mode.html](http://doc.norang.ca/org-mode.html)

<comment> a-saleh Second emacs org-mode.

I use almost nothing out of it. I have the default spacemacs configuration. I literaly just write bullet lists and cycle TODO and DONE states on them. Still the best todo-manager :)

<comment><USER3> I've done a ton of writing and system description. I've got kit in Illustrator, I've bought tools on the mac like Scrivener[0] and Scrapple for writing fiction and technical documentation. I can really move with Omnigraffle. I've bridged that gap with writing my own tools in Python with JS web display layers. I am a competent developer in a few languages and I have known about emacs and org-mode for going on a decade.

I take big stabs at it becoming my goto. I feel like I've done a lifetime of development to just dance around figuring out this tool.

Do you have any suggestions for making it stick? I'm making 2019 my year to really get emacs and put some time into fun Lisp. Any tips relating specifically to org-mode and not just "how to not quit using emacs" would be greatly appreciated.

[0] [https://www.literatureandlatte.com/store](https://www.literatureandlatte.com/store)

<comment> mickael-kerjean > "how to not quit using emacs" would be greatly appreciated.

Emacs kinda feel like a weird animal when getting started but that's just muscle memory. The best way to have it stick is to get a better understanding of its power. I wrote a 5 episode tutorial series that should get you on the right path: [https://mickael.kerjean.me/2017/03/18/emacs-tutorial- series-...](https://mickael.kerjean.me/2017/03/18/emacs-tutorial-series- episode-0/)

<comment><USER3> Very cool! I just skimmed the series and sat with Ep1 a bit. I will work through it this coming week and see how it lands.

I like the format. Thanks!

</comment></comment></comment></comment></comment><comment><USER4> KeePassXC has been great for password management.

Redshift for blue light filtering, although KDE now has that built-in.

zsh and the oh-my-zsh suite has been really helpful

A bunch of cli tools are nice. Ripgrep is a super fast grep tool that comes in handy for searching inside of files... can basically search your whole filesystem at lightspeed.

</comment><comment><USER5> In addition to the usual suspects of tmux, random window managers + friends, here are the applications I have to install to function

rofi - Fast, phenomenally good launcher

terminator - Terminal that allows splitting, tabbing, and more importantly bonding

redshift - Literally, shift my red light levels by time of day

retext - I write a lot of markdown. Seeing it real-time previewed makes life significantly better for me.

steam - A distraction now and then certainly helps

<comment><USER6> I've struggled for a long time with paper scraps to keep track of what I've been doing and read about the following alias to add in your .bashrc

`alias did="vim +'normal Go' +'r!date' ~/did.txt"`

Then type `did` in your terminal and write what you just did.

More generally, you can get a great boost of productivity by mastering your text editor. I have a preference for Vim, but have nothing against emacs.

</comment></comment><comment><USER7> \- i3 window manager - I just couldn't go back now. Over the course of the last 5 years I have saved time and made window management much less painful.

\- Parcelite clipboard history - very useful for various reasons. It's such a basic tool for me now I don't know how people live without one.

Not a tool, but for any shell work learning the readline key bindings is a good time saver: Ctrl+a/e/n/p/b/f. It's just so much more clunky using other keys

<comment><USER8> +1 for i3. I have a 13" laptop as my primary driver and using i3 is so much faster & convenient on such a small screen. Though I have made 2 changes to my workflow to get better out of it:

\- I use i3 inside XFCE. This allows me to use the xfce launcher, status bar, tray icons and other goodies, e.g. adding external monitor pops open the display properties, volume bar is available anytime. All this saves me from binding buttons & doing other changes in my i3 config.

\- Since Win+{1,2,...0} (buttons which change workspaces in i3) are now hardwired in my brain, I have arranged the icons on the taskbar of my Windows-10 machine to what I have in i3.

Win+1 is assigned to Emacs on i3, so that's the first icon on my windows taskbar.

Win+2 -> shell/git bash

Win+3 -> Thunar/Windows Explorer

Win+4 -> Firefox/Firefox

Win+7 -> Anki/Anki

This saves a lot of brain cycles, as my Windows workflow is also a bit like what I usually use on Debian.

Last week I try using EXWM but wasn't able to make it work as per my expectations, so switched back to i3, but EXWM is definitely a TODO on my list.

<comment><USER9> 4 / 5 window arrangements i use the same except Thunar. I dont remember why i choose that particular arrangement. Did you copy from some where ?

</comment></comment></comment><comment><USER10> Tmux, vim + handful of plugins, i3wm, mutt, qutebrowser. Without the ability to completely control my systems from the keyboard, I would suffer a bit hit to productivity and these applications allow me to do that.

<comment><USER11> also ranger for file management and saka key firefox/chrome extension

<comment><USER10> I prefer using no specialized application for file management. ls, cd, (rip)grep, find, less, tail, and others work perfectly fine.

</comment></comment></comment><comment><USER12> The one app is i3wm. People say tiling wm do not help boost productivity, but it certainly did for me -- or at least I think that it did.

From hardware aspect (although it was never asked), I use a hhkb type-s with the hasu controller. You may think it's a small change, but the fact that you can remap the arrow keys to {h,j,k,l} also helps because you no longer need to stretch your arm to your arrow keys. It did cost a bit of money, but I'm happy that I have it. And aside from the arrow key remap, I also remapped other keys to help with basic functionalities.

</comment><comment><USER13> Rofi is pretty great.

I'm also shamelessly addicted to guake (drop down terminal). I know there are more robust alternatives, but having grown up with Quake/CS, it just feels right.

<comment><USER14> I wanted to use Yakuake but it's for KDE and didn't want to install a complete DE just to use its dropdown terminal. Guake is a fairly good alternative, but I'm having an issue with it that it somehow makes title bars and top menus unclickable, which forces me to terminate it every now and then start it again.

<comment><USER13> I have not had those issues, and I'm actually using guake with KDE atm. You might be able to get yakuake working on non-kde. What DE are you using?

<comment><USER14> I have XFCE, but when trying to install, it included the whole KDE DE as dependency, which I don't really need.

<comment><USER15> You can launch xfce-terminal in drop-down mode..

</comment></comment></comment></comment></comment><comment><USER16> Off the top of my head, I'd suggest the following:

\- Flameshot for screenshots and annotation [1] \- Albert Launcher [2] \- Jumpapp for quickly launching or switching between windows [3]

They are all desktop agnostic.

[1]: [https://github.com/lupoDharkael/flameshot](https://github.com/lupoDharkael/flameshot) [2]: [https://albertlauncher.github.io](https://albertlauncher.github.io) [3]: [https://github.com/mkropat/jumpapp](https://github.com/mkropat/jumpapp)

</comment><comment><USER17> Switched around the same time as well from MacOS. I really missed Spotlight. A suitable alternative I use on my Lubuntu 16.04 machine:

[https://cerebroapp.com](https://cerebroapp.com)

<comment><USER18> This is a nice app. Thanks for sharing!

<comment><USER17> sure! :)

</comment></comment></comment><comment><USER19> I mostly use the command line, so Zsh and its extensive support for tab completion is the most important thing.

rsyn^I e.o^I:/va^Iw^I/ ./ -av --prog^I

autocompletes to

rsync example.org:/var/www/ ./ -av --progress

with alternatives listed if I press tab sooner (e.g. --protocol, --protect- args are shown with the purpose of those flags).

On a local filesystem,

ls /v/w/h/i^I

autocompletes to

ls /var/www/html/index.html

The non-default shell tool I use most often is "jq", a JSON processor. I can interact with a REST API, and answer a lot of one-off queries _just in the shell_.

I should probably write a tab-completion module for our REST API...

</comment><comment><USER20> *nix specific: tmux, clipit cross platform: jupyter-lab, vim.

</comment><comment><USER21> Switching back to Mac OS X is what really boosted my productivity as it allowed me to forget all about constant fiddling, broken drivers, breaking updates, inconsistent UX/UI, amateurish applications, etc.

My Ubuntu box (an Ubuntu-approved Dell tower IIRC) required constant attention and ultimately died after two years while my mid-2011 Mac Mini went through 4 major Mac OSX/MacOS versions and countless security patches without a single issue and all the company-provided MacBooks I've had since 2010 have been zero-maintenance.

<comment><USER22> Counter-anecdote: I've been running an Arch install for 2+ years with zero problems. Picking hardware that has direct kernel support will save you a bunch of headaches.

Also, a rolling release distro, which you'd think would be less stable, provides better hardware support as the kernel and firmware packages are _much_ more recent (not to mention libraries/build dependencies). Personally, I'd never go back to a fixed-release distro.

<comment><USER23> > Picking hardware that has direct kernel support will save you a bunch of > headaches.

Yep, that seems key. I've just spend full 5 days (I'm in between contracts, so I have the time) trying to install Arch on my Early 2013 15" MacbookPro. I turned out that, due to buggy/nonstandard hardware, a fully functional dual boot with Windows is not possible (if your disk is GPT, you won't have sound on Windows and if it's MBR, the DisplayPort monitor won't come back from suspend on Arch). Just coming to that conclusion took around 4 days of experiments. I've spend one more day trying to set up wireless, and have just given up. There are more interesting things to do with computers than finding workarounds for a minefield of hardware/firmware/drivers bugs.

<comment><USER22> I had a late 2013 MBP and went with the XPS 13 for that reason. The process to dual boot (or even wholesale replace) a MBP on Linux looked _really_ scrappy. I get it, Apple's UEFI firmware is essentially a black box with zero configurability. If that's how the process starts, I can't imagine how painful the rest of it is.

</comment></comment></comment></comment><comment><USER24> iptables. I actually block some websites by setting some rules in /etc/rc.local like:

iptables -A OUTPUT -p udp --dport 53 -m string --hex-string "|08|facebook|03|com" \--algo bm -j DROP

Not joking

</comment><comment><USER25> _Shutter_ is a great little gui tool I use everyday, it let's you easily take screenshots or partial screenshots and mark them up before copying/saving them.

<comment><USER18> Yeh shutter is a great application! Very easy to use and most importantly, light weight.

</comment></comment><comment><USER26> I mostly use the command line. I use Heirloom-mailx for email, i3 for window management (although I wrote my own program for the status bar), vim for text editing, just the shell commands for file management, xterm for terminal emulation, xclip for clipboard management, SQLite for database management, and I wrote my own programs for screen capture and many other things. I do not have a launcher menu; I just start all programs from xterm.

</comment><comment><USER27> Alpine is absolutely amazing for managing the hundreds of emails I get everyday. Also, workrave helped with concentration by forcing me to do regular pauses.

</comment><comment><USER28> I suggest:

\- AutoKey (key shortcuts)

\- Conky (desktop widgets)

\- lsyncd (syncing files)

<comment><AUTHOR> lsync looks really good. Currently I was using rsync with a custom gulp script to mimic similar functionality.

<comment><USER29> I've been using unison lately. Nice and quick over 1000s of files between OSX and Linux. A little slower when paired with Windows though

</comment></comment></comment><comment><USER30> I'd suggest a clipboard manager. I use Glipper, but there are a lot of others.

<comment><USER18> copyq is very good as well.

<comment><USER31> CopyQ is the best clipboard manager, IMO! I used to use Glipper, CopyQ crushes it!

</comment></comment></comment><comment><AUTHOR> To add another one of my favorite: gotop[1] (drop in replacement of htop) is really good.

[1][https://github.com/cjbassi/gotop](https://github.com/cjbassi/gotop)

</comment><comment><USER32> \- Zim - very light note taking application

\- Clipit - clipboard management

\- i3 Desktop window manager - gave me a superb boost of productivity

\- Indicator Netspeed unity - live network consumption/speed indicator applet

</comment><comment><USER33> Mkusb for making USB thumb drive bootable ISOs. If you want to try a lot of "flavors" it can definitely save a lot of time configuring ;)

</comment><comment><USER34> Listed app seems to be only the obvious ones that has good alternatives on other OS but aren't there any that is better on Linux desktop?

</comment><comment><USER31> * Fish shell: Specifically, its abbreviation feature. `abbr --add word phrase`. e.g. `abbr --add g git`, then I don't have to deal with autocomplete support for non-native command names as it literally expands to git after I type it followed by a space or return.

It also allows for faster throw-away function editing and saving if you want to keep it. `function`, `funced`, `funcsave`, `functions`

* Tmux: Use pane splitting so much, always frustrates me to see others moving so slowly through terminal windows and tabs. bonus: I also have pane splitting to re-attach to existing SSH connection if it was split from a SSH session.

I used to use tmuxinator and probably will again, more valuable if multiple projects simultaneously.

* Guake/Gnome Drop Down Terminal: Terminal dropdown is just such a huge time saver.

* z: jump to recent directories, [https://github.com/jethrokuan/z](https://github.com/jethrokuan/z)

* fzf: get ctrl + r history search functionality back that bash provides, also provides ctrl + o to open files in $EDITOR [https://github.com/jethrokuan/fzf](https://github.com/jethrokuan/fzf)

* copyq: Best clipboard manager evah! You NEED a clipboard manager, can't believe I went years without it, I trigger mine with ctrl + alt + c

* pipe to clipboard: `<command with output> | xsel --clipboard`, wrap xsel in a `cb` abbreviation in fish for autoexpansion. `abbr -a cb xsel --clipboard` may need to install `xsel` first.

* workspace tiling: I map 9 workspaces to the same grid on the keyboard with these keys + an <alt> modifier. I also assign certain applications to always auto-assign to specific workspaces:

w e r

s d f

x c v

* clock: set it to show seconds, you can easily perform loose timing way. Use `time <command>` if you are on the terminal.

* timezone: if you work with a team who is in one timezone, just set it to use their timezone during working day. I made a script to toggle this back and forth easily

I also display my timezone in my tray if I am toggling timezones.

* Arch Linux: On previous distros I would have to futz with package sources way too much. With Arch it is the easiest and most productive ever by using the `yay` package manager/wrapper. I can type `yay -S <package name>` and 99% of the time it will be available and even automates building it from source if there isn't a binary. It just works, I will never go back. Arch has some of the best packaging out there, I will use Arch for this reason alone, it saves many hours of time.

* ethernet cable: I use ethernet cabling whenever possible. Lower latency times and in video conferences you can say "not me" when the stream breaks down. Results in you not having to troubleshoot wifi. Using wires is amazing!

* Jabra 410 WIRED speakerphone: one reason, hardware mute button. Don't have to fiddle through windows to see if you are on mute. Big red ring around the speakerphone shows if you are muted or not.

* Screen annotations + touchscreens: The reason to use a touchscreen with linux is screen annotations. Arch + Gnome 3 works well enough with `yay -S gromit-mpx` as an alternative to Compiz Annotate. This saves time because during presentations you can communicate much more efficiently by drawing a red circle around something. You don't need a touchscreen and can use a mouse pointer, but that does slow things down, still better than no annotations though.

* noise cancelling headphones: this is the best investment I have ever made. Do this.

* Focus music: "hey google, play focus music" and also I purchased lifetime subscriptions for brain.fm and focus@will. I toggle between the 3. Combined with noise cancelling headphones you can get into some killer focus zones with these!

* rubber ducking: similar to other posts here for marking @todos etc, which I may look into their suggestions for a CLI method. But for now I use a running Google Doc where I write it out for getting stuck and making progress. Here is an article I wrote expanding on this blurb. [https://medium.com/@ElijahLynn/write-it-out-f9c74082e6ca](https://medium.com/@ElijahLynn/write-it-out-f9c74082e6ca)

* 2-5 minute runs: Sometimes just gotta get up and run. I run around the block, it doesn't have to be long. A goal of once around the block is super good for brain health, more is better but 2 minutes is really a good start. My long-term goal is to do a 2 minute run every hour during the day.

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=

Here is my most recent Arch setup with most of these tools listed, it is pretty messy and I didn't document everything in there but maybe it is useful to someone, there is also a video recording of how to install Arch + Gnome 3 at the top of the document that my friend and colleague Cameron Eagans walked me through with some great discussion around UEFI & BIOS. [https://docs.google.com/document/d/1QtQyveacu8dgTeoy8939Ti42...](https://docs.google.com/document/d/1QtQyveacu8dgTeoy8939Ti426eifC_GqJKaVhNu0bN4/edit)

Gosh that was way longer than it was intended to be, original intent was just to write about `fish abbr --add` which you should switch to fish for that reason alone!!

<comment><AUTHOR> Really appreciate for taking the time to answer my question.

I use zsh myself. Have not tried fish yet but only heard good things about it.

Also, regarding the pipe to clipboard, I liked the 'pbcopy' command on Mac. So, right now I have added an alias pbcopy='xclip -selection clipboard'. It's really handy.

</comment></comment><comment><USER35> I use Zenkit (project management tool) to organize all my tasks and keep track of the progress. It's also available as Snap.

</comment><comment><USER36> gitg is pretty helpful for visually checking changes before committing. I prefer it to text-more diff and use it for projects that don't require IntelliJ.

</comment><comment><USER18> KDE Connector

Shutter for screen shots

parsec for streaming a local windows box

</comment><comment><USER37> alias s='cd ..'

</comment><comment><USER38> Compiz? Are you joking? In what way could Compiz boost your productivity?

<comment><AUTHOR> All the bindings, hot-corners, expo to name a few.

</comment></comment><comment><USER39> Figma for UI design.</comment>


Show HN: Mixshake – Free personalized internet radio - <AUTHOR> https://mixshakemusic.com <comment><AUTHOR> Hey everyone, I'm Itay, the creator of Mixshake, a music streaming service that generates a genre-mixing playlist with an infinite number of songs.

Like many people, I love to listen to music - while I'm working, driving, working out and, of course, chilling with friends. My favorite way of listening is to explore and combine several genres at the same time. My favorites are: dance, alternative and pop. I've been using many music streaming services and, unfortunately, I didn't find a service that allows me to listen to mixed-genre playlists and to change the playlist dynamically, according to my current mood. I found that this feature is missing everywhere - even on the larger streaming services.

This is why I created mixshake, a web application where you can do exactly this - stream music from YouTube and combine all the genres of music you like. The user chooses his/her favorite genres and the application generates an infinite playlist for him/her according to his/her choices. While playing, the user can tune the genres, for example, select "more pop" and "less alternative" and the playlist regenerates dynamically.

I would love to hear your feedback! If you have any tips or suggestions on how to build my community and drive traffic/new users, I'd be very happy to hear it.

Thank you in advance for your time and great ideas.

</comment><comment><USER2> Really cool concept!

<comment><AUTHOR> Thanks for your feedback!</comment></comment>


Japanese Lisp Manga - <AUTHOR> http://lambda.bugyo.tk/cdr/mwl/ <comment><USER2> You might also check out these Manga Guides: <http://nostarch.com/manga/>

</comment><comment><USER3> this is awesome, i wish there was a translation

<comment><USER4> [http://www.reddit.com/r/programming/comments/a29qx/japanese_...](http://www.reddit.com/r/programming/comments/a29qx/japanese_lisp_manga/c0fiojr)

And there's some lisp source code in the chapters.

</comment></comment><comment><USER5> I guess lispers would be able to learn some japanese from this.

</comment><comment><USER6> so I suppose many here can read Japanese since they vote it up? What about a round up/review? Me no japan.

<comment><USER7> _so I suppose many here can read Japanese since they vote it up?_

ええ、判りますよ ^^

<comment><USER8> You may have meant 分かります or even perhaps 解ります but 判ります is closer to "to know" in the sense of judgement, as in "It is a handy to have a dictionary around when you don't know which of the homonyms is the most correct usage." (It is perhaps easier to remember if you know the word 判断 already.)

(Are you perhaps writing on Linux? Word to the wise: the Microsoft IDE typically presents alternatives in the order of most commonly used, which is helpful for language learners because typically they don't know obscure, error-prone usages like that. Most IDEs I've used in Linux present words in an order I can't even begin to comprehend -- I mean, come on, who would predict 名護や to be what the user probably intended over 名古屋? This means on a Microsoft IDE you can usually just hit space bar and the thing that comes up will _probably_ be the word you know and meant, but for other IDEs you need to be able to pick the word out from the alternatives or, alternatively, read the inline usage notes and choose appropriately.)

<comment><USER9> As someone who made a run at learning Nihongo in the nineties, I bow to your awesomeness for your inductive reasoning.

<comment><USER10> そですね、僕も

</comment></comment></comment></comment></comment><comment><USER11> I have always regretted not taking lisp. I hope this is translated one day.

<comment><USER12> You could read+watch Structure and Interpretation of Computer Programs and pretend that, instead of a suit jacket and fez hat, Sussman is wearing a kimono, hair bow, and animal ears.</comment></comment>


The Real Villain Behind Our New Gilded Age - <AUTHOR> https://www.nytimes.com/2018/05/01/opinion/monopoly-power-new-gilded-age.html <comment><USER2> The real villain is the ignorance of the population at large. Marketing/Propaganda work surprisingly well though.</comment>


A French King Who Believed He Was Made of Glass - <AUTHOR> https://daily.jstor.org/french-king-who-believed-made-glass <comment><USER2> Wikipedia article about the psychiatric disorder: [https://en.wikipedia.org/wiki/Glass_delusion](https://en.wikipedia.org/wiki/Glass_delusion)

</comment><comment><USER3>
      All the king's horses
      And all the king's men
      Couldn't put Humpty Dumpty
      Together again

</comment><comment><USER4> I wonder what beliefs we have about human anatomy that will seem quaint/ignorant in some hundred years.

<comment><USER5> Involuntary circumcision of nonconsenting children, for one.

It should fall under "I can't believe people were this barbaric" along with virgin sacrifices and other practices that seem inconceivable now, but were sanctioned by pseudoscience and public approval just as this is.

<comment><USER6> > Involuntary circucumsion of nonconsenting children, for one.

Where do you live that that is considered common? Sounds utterly barbaric to me.

<comment><USER7> The US, maybe? It remains very common (over 50%). Or some country in Africa / Middle East / Southeast Asia where it's done for religious reasons. If you go back a few decades it was also quite common in other places like Australia and Canada.

</comment></comment></comment></comment><comment><USER8> The poor guy was mentally ill. I believe he went on a murderous rampage and nearly killed his brother and did kill some of the royal attendants. He also led a huge invasion of Italy which ended up in defeat for the French.

<comment><USER9> It was Charles VIII the Affable (reigned 1483-1498), the great-grandson of Charles VI the Mad (reigned 1380-1422), who invaded Italy.

</comment></comment><comment><USER10> This is a Cervantes short story:

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

</comment><comment><USER11> Once I had a love and it was a gas

Soon turned out had a heart of glass

<comment><USER12> Blondie?</comment></comment>


Show HN: The missing YouTube parental control on iOS - <AUTHOR> http://yestube.tv/ <comment><USER2> Nice. What I have noticed is the younger kids get out of the app. Then the parent has to go back into the app and press play again. (over and over). Not sure if there is a lock screen more where the kid can't mess up the controls.</comment>


Show HN: Watch LIVE Twitter photos related to #Sandy hurricane in real time. - <AUTHOR> http://livesandypics.com An app we made quickly using Node.JS, Express, Jade & Socket.IO to show photos uploaded to Twitter related to Sandy hurricane. <comment><USER2> Sorry as useful as this might be, it's totally hindered by UI issues. Pictures I'm trying to look at sporadically shuffle along, half of them are irrelevant, and there are heaps of duplicates and memes. The last two are forgiven since this was probably whipped up in haste, surely there's a site that allows filtering and quick delivery with a better UI?

<comment><AUTHOR> Thanks for your comment! We created it in about 15 minutes right when Sandy arrived to NYC, so we had little time to optimize it. It's showing in real time what's being shared over Twitter, it's not curated at all. Cheers!

<comment><USER2> No worries I totally understand. It'll be a useful service to some I'm sure. All the best!

<comment><AUTHOR> Thanks a lot!

</comment></comment></comment></comment><comment><USER3> Pretty much just a white screen for me, none of the pictures are loading. If I hover over where they are supposed to be I can see the related tweet. It also seems to be loading new tweets pretty fast. Can't say for sure since I can't see the photos, but I think it might be too fast to get a good look at any of them.

<comment><AUTHOR> Weird, most browsers show the pics as they're uploaded to Twitter. And yes, it's pretty fast because people are sharing lots and lots of pictures related to Sandy right now. Will try to slow them down, but it won't be real time anymore.

<comment><USER4> Just a white screen for me too. When I hover over I see the tweet text, but the images never load on the screen. Chrome 22.0.1229.94. Cool idea though!</comment></comment></comment>


Why Men Matter to Women in Tech - <AUTHOR> https://medium.com/code-like-a-girl/why-men-matter-to-women-in-tech-c143fc0bede0#.b1zlesawt <comment><USER2> "your voice holds more weight than us self-serving triggered feminists"

True story. I always do, mostly because I think it's the right thing to do, but also because most of the women I know aren't "self-serving triggered feminists" and I feel ashamed to be a guy when witnessing such behaviour from other men.</comment>


Arithmetic vs. Reality: The Sawdust Principle - <AUTHOR> http://www.thegrumpyprogrammer.com/2017/03/arithmetic-vs-reality-sawdust-principle.html <comment><USER2> Somewhat similarly, it annoys me every time someone rounds off decimals in the middle of some calculation. You round at the _end_ , not in the middle, _even if the amount rounded off is tinier than a single atom_. Edward Norton Lorenz found this out, and called it the "butterfly effect".

<comment><USER3> I remember being taught about approximations, rounding and significant numbers near the end of primary school. It was part of explaining why the calculators we used[0] displayed 1/3 as 0.333333 (because they rounded internally, of course). And, we were told, because a lot of calculations with calculators had this rounding error, those last few numbers we saw on the screen would be incorrect, especially if we did repeated multiplications and additions with them. So, our maths book instructed, we had to round down our answers to the same number of digits that we started the calculations with.

This, of course, was not at all the right way to explain what significant numbers are, but that's how they were introduced to us.

Anyway, I figured that (obviously) rounding after every step would only create a bigger error, so it would be best to only round at the end to get the best approximation. Then my teacher docked points for that. One of many _" and I still kinda feel upset at my teacher for that"_ memories.</comment></comment>


New RFID technology helps robots find household objects - <AUTHOR> http://www.news.gatech.edu/2014/09/22/new-rfid-technology-helps-robots-find-household-objects

<comment><USER2> If we're trying to introduce robotics, getting the robot adapted to the environment as it stands now is only one approach. Getting the environment to be suitable to the robots is at least as important. I wonder what other infrastructure we'll have to provide to robots... it seems like a lot people are working more universal solutions to charging up robots at they go along.

<comment><USER3> I keep wanting to take a small inflatable blimp and have it fly around. Infrastructure would then be a small landing pad with an electromagnet to hold the buoyant blimp up so the fans don't have to continue to run while charging. For charging i've been thinking of using the same tech as wireless charging pads for cell phones. This means I'd need somewhere the blimp could find as home to land on. As far as helium replacement I haven't figured out a sane solution yet. Combined with this rfid improvement then I'd possibly be able to finally have a computer that i can ask "Where the hell are my keys" when I'm running late for work in the morning.

<comment><USER4> You might be able to work off of a nexus 5 and the official charging pad as a starting point. They've got magnets (though permanent, not electromagnets) to hold the phone in place when charging.

</comment></comment></comment><comment><USER5> Cool! I'm glad to see RFID and localization being merged together like this. I think this really shows that RFID is a much more suitable technology for this type of application than a computation-heavy CV algorithm.</comment>


Apple's 2018 MacBook Pros Attempt to Solve Flexgate, Without Admitting It Exists - <AUTHOR> https://ifixit.org/blog/13979/apples-2018-macbook-pros-attempt-to-solve-flexgate-without-admitting-it-exists/ <comment><USER4> A bigger problem imo is the $700 display replacement. I have a similar problem with my wife's broken MacBook, where replacing the display costs almost as much as the computer itself.

The problem with the MacBook is that the display is bonded to the glass and the aluminum back so that you have to replace the entire top assembly to fix the display.

It's even more depressing to know that the ribbon connecting the display is also soldered on.

Apple (and Ives in particular) talks a lot about recycling, sustainability, and product lifecycle, but that seems like complete bullshit once you actually open up or try to repair one of their products.

<comment><USER5> Yep, Louis rossman, a popular apple repair guy on YouTube talks similiar about this a lot. The overwhelming majority of problems are fixable for 10 minutes or less and less than a dollar in components. But apple will just tell you to buy a new board and purposefully makes it harder for repair. The whole 'sustainability' is a marketing act.

<comment><USER6> There was a hyped report where they said they recovered over 2204 lbs of gold from their hardware, this number quoted in every news story: [https://www.geek.com/apple/apples-recycling-program- recovere...](https://www.geek.com/apple/apples-recycling-program- recovered-2204lbs-of-gold-last-year-worth-40-million-1652481/)

2204 lbs is 1000kg converted to lbs, rounded down. If that's not a marketing number I don't know what is

<comment><USER7> They probably recovered less if there was less hardware to replace. You can't recover much gold from only a ribbon cable versus an entire display assembly.

</comment></comment></comment></comment><comment><USER8> There are many examples of Apple never admitting design issues!

Beside what they are doing with their reputation and customers loyalty, I'm wondering how is it going to affect their engineering culture within the company itself.

They are very biased with their strategies in everything and they hardly change them. Same situation Microsoft was in some years ago.

<comment><USER9> I don't know about others, but I don't dare to buy Apple products anymore. My 2012 MacBook Pro is still going strong, but newer MacBooks don't have anywhere near the same build quality and durability.

When you have an issue, and complain about it or even ask advice what to do, I've often encountered toxic behavior from Apple fans. Denying the problem's existence and such.

The problem is of course what to heck to buy. MacBooks do have nice features, like fast wakeup and an excellent touchpad, that I still haven't seen matched in the "Windows" laptop camp.

<comment><USER10> I got a Dell XPS 13 last year and the touchpad is great. I use it both on Windows and Ubuntu.

I also remember having a Toshiba something-or-other 10 years ago and hating the touchpad in comparison to a Mac. So, just saying, I've seen how bad it can be. The XPS has given me no issues aside from having to make sure I change the click behavior (tap to click really annoys me).

<comment><USER11> Does tap-to-click really get in the way if you turn it on but don't want to use it? Are you 'tapping' as your finger comes down onto the trackpad to move? That action should be detected and ignored, IMO. I'm only saying this as a tap-to-click user. I can't stand using someone's keyboard if they've turned it off — there I am, tapping away, looking like an idiot ...

<comment><USER12> I find that I graze the touchpad with my thumb or palm while I'm typing. I always turn it off on my laptops.

<comment><USER13> This is another reason I don't want to leave Apple - they are far and away the best at detecting mis-taps.

</comment></comment></comment></comment></comment></comment><comment><USER14> I have owned 3 Macbooks so far. And all 3 have had one of the speakers break. Am I just that unlucky?

Oh and yeah, what a diarrhea of a keyboard in the 2016 edition.

<comment><USER15> I hate hate hate the newer Mac keyboard. Diarrhea is absolutely the perfect word to describe my feelings toward it.

<comment><USER16> I love the newer Mac keyboard. It is hands-down the best laptop keyboard I've ever used. Literally my only complaint is the design of the arrow keys.

<comment><USER17> I'm not an Apple fan boy by any stretch but years ago I discovered that the Apple 104 key keyboard suited me down to the ground. Despite using it mostly on Ubuntu and Windows. I've put up with strange key mappings just to use that keyboard.

The MacBook Pro I've just gotten at work is a nightmare. I assumed this was just getting used to it until this weekend when I finally setup my desktop at home with the old 104 key keyboard. The difference is night and day.

<comment><USER16> For what it's worth, I hate laptop keyboards in general. The MBP keyboard being the best laptop keyboard I've ever used is, quite frankly, an extremely low bar.

<comment><USER15> My older generation MBP keyboard (2015?) Is really good, best laptop keyboard I've touched. The newer one is just painful. I don't even know what I don't like about it, it just feels terrible, maybe because of how short the travel is. The key bottoms out immediately and it feels like I'm just tapping my fingers on a solid surface.

</comment></comment></comment></comment></comment></comment><comment><USER18> The one thing that caught my attention is that "they keep deleting the issue we post". That is an evil thing to do.

<comment><USER16> Question: do they delete any other posts, or just ones alleging design flaws? Do they give any reason for deletion?

<comment><USER11> Accidental Tech Podcast dealt with this recently: Apple's support and bug tracking is really low-standard, by all accounts. Apparently, they frequently mass-close bugs (e.g. after a new release) with a comment to the effect of "if this is still a bug, please reopen it". You can understand the circumstances that might've led them to do this ... but it doesn't sound great.

<comment><USER16> As someone who files an extremely high volume of Apple bug reports, that's not actually true. They _occasionally_ close a bug with "please try again and let us know if it's still happening", but that's extremely rare. And to be fair, the last time I saw that happen, the bug in question had actually been fixed at some point in the past. I'm pretty sure in that instance some engineer said "hey wait, that sounds familiar, I think we fixed that already, but I can't find the original bug report".

</comment></comment></comment></comment><comment><USER19> Nice knowing that, in addition of three failing keys (u, i and o) and one failed speaker, I can also expect the display flex cable to fail. 2017 MBP that's been plagued with problems from the very beginning.

<comment><USER20> Ugh - I have one that also has a left failed speaker, which had previously crackled before giving out. A quick search on Reddit will find similar reports. Apple refuses to acknowledge the issue entirely.

</comment></comment><comment><USER21> The weirdest part of all of this is the recurrent problems of Apple products in peoples tech-life-time, and the same people, while annoyed, embrace it... and I just don't get it.

If products fail on you consistently, why you keep buying them?

It's 2019, there's a lot of great products out there, with way more quality than some Apple products.

If the problem is the "ecosystem" you bought into, well maybe it was a mistake to begin with because it seems it's not much of a balanced ecosystem - <USER2> maybe you should consider jumping out of it.

I know I'm biased because I've been a windows user all my life, and I'm not from USA where Apple reigns supreme and people communicate with each other via Apple products/apps... but damn, is it really worth it? Because you're being part of the problem, not part of the solution.

<comment><USER22> Let's be clear about this: we have no idea how often this issue is occuring. From what we're seeing it could be 0.0001% of Apple Laptops failing within 3 years. This just tends to get a lot of attention. If you buy an Acer laptop it'll probably be 10x more likely to break in 3 years, but no one cares because the Acer brand is crap.

This isn't surprising, the likelihood of breakdown is just 1 aspect of choosing to buy a laptop.

There might be 'great' products out there, but my experience is that Windows is a total turd and so even if you could find hardware as good as Apple's your still torturing yourself everyday. There's loads of reasons to make the choice and a tiny % chance of your laptop breaking isn't going to completely convince people not to buy.

<comment><USER21> Well in the past years some of Apple products have had serious issues - <USER3> engineering flaws that made their products prone to issues.

So it's not just this issue.

About Acer, you'll have to back it up with something, because you know, Acer has laptops that range from 300€ to 1500€+.

But you're right, just because it's Apple these problems have a different reach in media, but on the other hand, Apple doesn't own their problems. And to top it off their practices when it comes to support some of the issues is just ridiculous.

To say windows is a total turd makes you look like you're just trying to hurt it's feelings, because you know, and I know, and everyone knows Windows serves it's purpose for plenty of people. Just like Android does.

If only the problems were in Apple laptops... the problems is in other product lines, and in the way Apple designs their products. Decisions like pinning down a laptop keyboard with rivets, poor choice of materials, poor thermals, the list goes on.

But hey, rejoice on it.

</comment></comment></comment><comment><USER23> A classic Apple move. Then a year later, they will offer to "fix" the affected model with "reasonable price", and people still have no choice but to go along with it.

<comment><USER24> just like their generous $30 battery replacements on iPhones after they were caught slowing down the iphones.

<comment><USER25> > they were caught slowing down the iphones

This is a mischaracterization of the issue. They communicated battery throttling poorly; they weren't "caught slowing down" iPhones.

<comment><USER24> They never acknowledged the issue even though the issue has been there for quite sometime[1].

[1] [https://www.collective-evolution.com/2017/09/03/study- sugges...](https://www.collective-evolution.com/2017/09/03/study-suggests- that-apple-deliberately-sabotages-old-products-iphone-slow-peaks-after-every- new-release/)

<comment><USER26> In all honesty, a battery is a wear and tear item. At some point it simply cannot provide enough power - it has been this way ever since rechargeable batteries was invented.

What Apple did was the only thing they could do to keep the phone working reasonably, but they should have communicated it clearly, and offered battery replacement for a reasonable price (30$ for iPhone 6 battery replacement was cheap).

Other manufactures have this issue too, and some phones like the Nexus 6p was extreme. In the old days the battery was user replaceable, and it was well known that you'd have to buy a new one at some point.

<comment><USER27> No. I don't buy this. The correct action would have been to overprovision the battery such that it is capable of advertised performance for the expected lifetime of the product instead of making the product 1 mm thinner.

<comment><USER26> Weight is important for a handheld device. 1mm thicker would add a significant chunk of weight.

The issue wasn't as much capacity, as it was peak power draw. While somewhat related to capacity, 10-20% larger battery would not have made much of a difference. They could have crippled the performance and lowering the peak power draw, but that was what they did when it was necessary.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> I also never see much talk about the sharp edges of Macbook. It was a struggle for me when I got mine. But just yesterday I checked the 2018 model of a colleague. And the sharpness was even worse. More importantly the vents on the side and on the around the hinge were really bad. My skin was scrapped painfully if my hand dragged across it. I don't know how one can use this safely without scratching one's skin :(. I like a lot about the Macbook itself while I also hate some of their choices. But this package they put everything is in sharp, slippery, zero grip is simply beyond absurd for me. That's not even talking about the repairability or making it so thin than it's harder to grip.

They have solved a lot of the tough problem of quality manufacturing and set a price for themselves to allow it profitability. That's the big thing. The problems Macbook has I feel are not about lack of engineering skill. It's completely about designer ego and fleecing the customers.

</comment><comment><USER29> I regret not buying a stash of 2012 Macbook Pros and hoarding them for my own use.

 __Edit: And iPhone SEs as well

<comment><USER30> Careful on the mid-2012 MBPs... as much as I love that machine, they also have their own flexgate [1]. The internal SATA flex cables bend across the Superdrive and rub against the slightly abrasive back plate, so they have a high failure rate if you actually use your device as a laptop (eg travel with it, keep it in an backpack). Apple seems to have had a problem with flex cables for nearly a decade now.

My MBP 2012 has had 6 SATA flex cable replacements by Apple in 3.5 years (I bought mine in 2015). The last few repairs have all been ~3 months apart. It's easily the most unreliable laptop I've ever owned. Thankfully Apple did all the SATA cable replacements free as required by law in Australia.

That said, you should be able to find mid-2012s for about $450 - $650 US refurbished from mom & pop Mac repair stores. [2]

[1] [https://forums.macrumors.com/threads/sata-cable-problem- in-m...](https://forums.macrumors.com/threads/sata-cable-problem-in-macbook- pros.1616970/)

[2] [https://www.macofalltrades.com/apple-macbook-pro-13-inch- glo...](https://www.macofalltrades.com/apple-macbook-pro-13-inch- glossy-2-5ghz-core-i5-mid-2012-md101ll-a/)

<comment><USER31> Okay real talk do people just not take care of their machines or have my friends and I been insanely lucky?

I use my computer daily and travel with it in a backpack all the time and have never once had anything on 5 Mac's I have owned (3 different work computers, 2 personal) break up until this year with the keyboard on the 2016/2017 MBP which in indeed a mess/huge fuckup. I still own both my personal Mac's and besides being pretty slow the 2012 can still run great in a pinch.

Many of my friends also own Mac's and not one has had issues with flex cables, screens, speakers, ports, you name it, until the butterfly keyboard issues. I can't help but wonder if it's a matter of treatment and defining what "regular" use is.

<comment><USER30> I mostly agree - I have a Pismo G3, 2006 Black MacBook & 2007 Black MacBook that are still in working order. The 2006 had one minor repair but has been fine ever since. I've been that guy who evangelized Mac reliability & AppleCare service to others.

I've been scratching my head trying to work out what I might be doing differently with my 2012 that others don't. The only thing I can think of (besides the backpack) is that I still make use of the internal DVD drive, and that I still have a spinning disk rather than an SSD (I need storage more than I need I/O speed). Perhaps the vibration from those devices causes some of the abrasion on the flex cables.

</comment></comment></comment></comment><comment><USER32> Bad news: Apple takes us for fools, again. this sucks.

Good news: many businesses and influencers (iFixit, Louis Rossman, Linus Tech Tips ...) are talking about it. This is bad press for Apple. The more noise we make about these issues, the better the chances are that Apple improves on its flaws.

I'm not overly optimistic about it: spreading the word about Apple's bad habits might be useless. But trying and failing is in my opinion better than not trying at all : at best, Apple makes better product ; At worst, they just keep on doing what they're doing.

</comment><comment><USER33> Still waiting for Apple to make anything anywhere as good as the Pismo was. I've had hardware issues of one kind or another with every single laptop from them since then.

[https://en.wikipedia.org/wiki/PowerBook_G3#PowerBook_(FireWi...](https://en.wikipedia.org/wiki/PowerBook_G3#PowerBook_\(FireWire,_Pismo\))

<comment><USER34> One problem with the Pismo (and probably other laptops at the time) was that the backlight would become very dim.

You could buy replacement backlights, but installing them was really difficult. Even if you managed to not break the very thin glass tube, aligning it in a way not to cast any shadows was tricky.

I think that the newer, LED-backlit displays actually have a much longer lifetime (apart from "Flexgate").

<comment><USER33> Anecdotal experience, but never had any issues with the Pismo, which I used well past the mid-2000s. I did have screen problems with the first titanium PowerBook G4, flickering, glitching, and then after a few months the thing just died and had to be replaced. That was after the hard disk failed as well in the first month of use. And it's been one thing or another ever since then. Being an Apple customer of several decades, I sincerely do not understand this myth of fantastic quality they have. I have had IBM and Lenovo fail much less, and HP... Actually never.

Edit : Just checked dates, and yes, I used the Pismo for 8 years. The PowerBook G4 barely 3 years and couldn't get rid of it fast enough.

</comment></comment></comment><comment><USER35> The display in my MacBook Pro 2017 just died recently. It was flickering for a week and then went all black (almost), except for a small line of pixels.

Together with the double-insert problem when hitting the space key, it's really total garbage.

</comment><comment><USER36> Environmental certifications should include repairability.

</comment><comment><USER37> The 2018 keyboard is much more robust than the earilier ones. In 8 months I haven't had to replace it at all (though I am close). I actually don't mind the feel, just want it to work.

And the Touch Bar...if I could just disable the hypersensitive virtual escape key (I use caps lock for that) it would be perfect...all else can be disabled but not that botch, for some reason.

I guess I still use it because I find the alternatives even worse. Could be Apple Stockholm syndrome.

<comment><USER38> You can easily disable the escape key on the TouchBar using the free Karabiner-Elements [https://pqrs.org/osx/karabiner/](https://pqrs.org/osx/karabiner/)

This is my setup: [https://d.pr/i/sP4OMX](https://d.pr/i/sP4OMX)

<comment><USER37> Hmm, that still doesn't disable the Touch Bar escape on my 2018 MBP. Any advice?

</comment></comment></comment><comment><USER39> Is there any signal that they are going to introduce a better keyboard?

I just can't grow to like the current ones.

<comment><USER40> They got a patent for putting key switches under a touchscreen, so my guess is that it's just going to get worse.

<comment><USER39> Oh wow, that's messed up.

</comment></comment></comment><comment><USER41> That's the company that removed strain relievers from all their cabling with the very intention of making them break easier.

What did you people expect?

<comment><USER42> Looking around my desk, I see a MagSafe power supply, with strain relief on both ends, a Thunderbolt cable, with strain relief, an HDMI adapter, with strain relief, a Lightning cable, with strain relief...what are you even talking about?

<comment><USER43> What strain relief, the crappy flex neck that stiffens over time becoming itself a strain point making the cables fray on their discontinuity? (Note how normally strain releifs are graduated... but let's not get function to prevail of form!)

I haven't had an Apple laptop without the darn thing breaking after a couple years... it's a tax, as well as guaranteed landfill material.

Just google "apple power supply cable fray"

<comment><USER25> And I haven't had a power supply break yet. I still do not understand how people manage to ruin these things, unless they're yanking them from the cord itself or twisting it around. It seems like they stay together if you put just a bit of care into keeping them intact?

<comment><USER44> I'm guessing you don't use your laptop in your lap. It is impossible to avoid some strain on the cable while the computer is on your lap, because it must hang unsupported.

Use it this way for a while and I guarantee that no matter how much you care, the plastic will splinter exposing the inner cables and eventually shorting them.

<comment><USER25> I _do_ use my computer in my lap; the strain is minimal and has no real effect on durability. That's like a couple of ounces of weight–there's no no way that will permanently damage the cable.

<comment><USER44> There should be no way, but as plenty of people can attest to... it happens. Really, why would so many people be complaining if it wasn't true?

I'm still using my late 2011 machine as a daily driver, day in and day out. I think you can agree I don't generally mistreat my stuff (or the thing would be destroyed already). I'm telling you I've been careful with the charger cables, and still got 3 of them to fry this way.

You may or may not believe me, but at least you should understand that my opinion (and many others') is that those cable strains are unfit for their purpose.

</comment></comment></comment></comment></comment></comment></comment><comment><USER45> Last years there are many fuckups with pro models.

</comment><comment><USER46> Interesting. This stage light effect also affects my 2007 mbpro which is two generous old. It did take about seven years to develop, but it seems that it's been an issue possibly on past models also that has just gotten worse with the latest thin design.

</comment><comment><USER47> I paid for AppleCare and Apple fixed my keyboard twice and replaced my display for free. No questions asked.

The counter-argument is that such an expensive machine should not fail.

Hardware suffers from wear-and-tear. My upfront investment for AppleCare more than paid for itself.

</comment><comment><USER48> Eventually Apple will make a disposable $3000 Mac and everyone will love it ...

<comment><USER49> Tired of this kind of lazy trolling on every article even vaguely critical about Apple.

</comment></comment><comment><USER50> Cook is a supply chain guy.</comment>