How the 8086 processor handles power and clock internally - <AUTHOR> http://www.righto.com/2020/08/how-8086-processor-handles-power-and.html <comment><USER2> Author here if anyone has questions about the 8086 internals.

<comment><USER3> Another great article. In some photos we see small circles labeled as "vias" and other's show small circles as "contacts." What exactly is the difference between vias and contacts?

<comment><USER2> No difference except how much space I had on the diagram :-)

</comment></comment></comment><comment><USER4> Wires on a chip are interesting. On a PCB you mostly have just two cases to deal with: low edge rate case, the trace is equivalent to a capacitor. Fast edge rate case, the trace is equivalent to a transmission line with a characteristic impedance, such as a coax cable- signals will bounce and you have to worry about termination. In both of these cases you can pretty much assume that resistance is zero (except for very high edge rates).

Now on a chip the traces are so thin that resistance is significant and can not be ignored. The trace can be modeled as a distributed or lumped RC circuit. A consequence is that the delay is a quadratic function of its length (doubling the length of the wire quadruples its delay). It becomes worthwhile to add repeaters. I wonder if these show up in 8086..

On the other hand, "For on-chip wires with a maximum length of 1 cm, one should only worry about transmission line effects when tr < 150 psec"

[http://bwrcs.eecs.berkeley.edu/Classes/icdesign/ee141_f01/No...](http://bwrcs.eecs.berkeley.edu/Classes/icdesign/ee141_f01/Notes/chapter4.pdf)

<comment><USER5> Well yes and no - at the time the 8086 was designed gate capacitance dominated over wire RC delays - early design tools (sort of pre-late 90s, way after the original 8086) didn't bother with calculating RC delays during synthesis and we only really dealt with them in late static timing analysis (and really then only for a few long lines).

Essentially as chip features got smaller wire resistance didn't scale the same as gate capacitance (partly it's edge effects) and our tools needed to change as RC delays started to dominate

</comment></comment><comment><USER6> > This chip divided its input clock by 3 to generate the 33% duty cycle clock > required by the 8086.

And the input clock was 4.77 MHz because that is one third of the NTSC clock, 14.318 MHz. The clock is further divided by 4 and that's the input of the 8253 programmable timer.

<comment><USER4> The 33% is only required if you want to run the clock at its maximum speed. If you run it at a lower speed, you can get away with 50% duty cycle and dispense with the 8284A clock generator chip. I've done this on some cheap embedded systems.. up to 4.2 MHz on a 5 MHz 8088 is OK..

<comment><USER2> That's interesting. The datasheet says the clock has to be 2/3 low and 1/3 high with just 17 ns of margin. It's surprising that the datasheet is so strict if you can totally violate the specification and still have it work.

(To be clear, I'm not disagreeing with you that this works.)

<comment><USER4> Well the spec is minimum cycle time = 200 ns, maximum cycle time 500 ns. But also it has min. low time = 118 ns and min. high time = 69 ns, which is how the 1/3 duty cycle shows up. But there is no spec violation with, for example, low time = 125 ns, high time = 125 ns for a cycle time of 250 ns (4 MHz).

<comment><USER2> Which spec are you looking at? Is it a later revision? I'm looking at the User's Manual [1] which says the CLK Low Time has a minimum of (2/3 cycle time)-15 and CLK High Time has a minimum of (1/3 cycle time)+2. That yields a minimum low time of 151 ns which is violated by the 125 ns value.

[1] page B-18 in [http://www.bitsavers.org/components/intel/_dataBooks/1981_iA...](http://www.bitsavers.org/components/intel/_dataBooks/1981_iAPX_86_88_Users_Manual.pdf)

<comment><USER4> This one, page 15: [https://course.ece.cmu.edu/~ece740/f11/lib/exe/fetch.php?med...](https://course.ece.cmu.edu/~ece740/f11/lib/exe/fetch.php?media=wiki:8086-datasheet.pdf)

Ah, I see in the older datasheet it says TCLCH = 2/3 * TCLCL - 15. But I'm pretty sure they mean TCLCH = 2/3 * TCLCLmin - 15 which gives the 118 ns it has in the newer datasheet.

<comment><USER2> Thanks! That makes more sense.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I've loved following this series of posts as an amateur/layman wanting to know more about the hardware behind the chips I use!

Here's a question for anyone who might have an interest to help me understand (at a high summary level) --

Steady DC power is being provided to the chip, and the internal clock is going at 5 Mhz. What are the input and output signals like? Are they on the order of a few kHz and in a long stream of data (in a short burst?) that the CPU then takes and works on until the "delivery" burst? Is this the FSB? How many of the 45 wires coming off the CPU are for the input/output signals, or what are the rest of them for?

Thanks!

<comment><USER2> The 8086 has 40 external pins [1]. There are 20 address lines shared with 16 data lines, so it's a 16-bit computer that can address 1 megabyte. The remaining pins are mostly assorted control signals. (Intel liked to keep the pin count pointlessly low, so the pins are multiplexed and have several uses.)

The external pins are switching at the 5 MHz clock speed, and there are four clock periods for one memory bus cycle. The address pins send out the address the first cycle, wait a cycle for memory to respond, and read or write the data the third cycle.

The CPU and the memory bus are working at the same clock speed. (Although somewhat decoupled because the 8086 had prefetching.) I think you're going the wrong direction with kHz I/O and delivery bursts.

I've simplified things a bit. The 8086 User's Manual [2] explains all the signals in great detail if you really want to know.

[1] I see that you carefully counted the 45 wires off the die. The power and two grounds each use two bond wires in parallel for more current. There are two wires to bias the substrate. So that's the "extra" 5 wires.

[2] [http://www.bitsavers.org/components/intel/_dataBooks/1981_iA...](http://www.bitsavers.org/components/intel/_dataBooks/1981_iAPX_86_88_Users_Manual.pdf)

<comment><USER7> Thanks! I will have a read through that manual!

</comment></comment></comment><comment><USER8> This is so simple and beautiful.

It is mainly because of lack of power saving and EMC requirements plus no clock skew problems at such low frequencies.

Nowadays you need a team of 50 people just for the clock tree.

</comment><comment><USER9> Also I find the following very intereating. Because no CADs existed, old CPUs were drawn with pen and paper. The process of getting it to lithography was called Rubylith.

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

Here are some historic photos with master prints of CPU

[https://www.team6502.org/](https://www.team6502.org/)

<comment><USER10> The origin of the term "tape-out".

Circuit boards were also designed in this way.

[https://www.eetimes.com/how-it-was-pcb-layout-from- rubylith-...](https://www.eetimes.com/how-it-was-pcb-layout-from-rubylith-to- dot-and-tape-to-cad/)

<comment><USER5> Yup, I did this as a kid in the mid 70s - PCBs were done at 2x, red and blue tape for 2 layers - you drilled holes yourself, no plated thru holes

</comment></comment></comment><comment><USER11> This is the one I personally have been waiting for. Thanks!

On the power distribution did you notice any bypassing? There are a number of ways to do it now. I have no idea how they did it, if at all, in the 70s.

Also, did you notice any trim or anything on the clock driver so they could match phase of clock and not clock?

<comment><USER2> There's no power bypassing on the chip, just the power lines.

There's no clock trimming either. The clock circuitry ensures that there is a gap between the two phases, but there's no adjustment. But at 10 MHz, the clock is not too sensitive.

<comment><USER11> That's really interesting. It seems like a foreign world compared to what I'm used to. :)

<comment><USER2> Do you want to say a bit about bypassing and trimming on modern chips?

<comment><USER11> It's a lot of information for a forum comment. I will provide a pointer though.

I think the book at cmosvlsi.com is pretty good for an introduction to the realities of modern digital IC design.

For more information on the topic of this thread in particular see slides 17-19 in this deck. I was asking if the cap on the far right of slide 17 existed in this design. [http://pages.hmc.edu/harris/cmosvlsi/4e/lect/lect21.pdf](http://pages.hmc.edu/harris/cmosvlsi/4e/lect/lect21.pdf)

On the trim: When I looked at the two phase timing figure provided I noticed if the bottom path through the clock driver was slower than the top path, due to manufacturing tolerance, then that could cause skew (see slide 24 in the deck I pointed to) between the phases which might cause phase 1 and phase 2 to get too close, or even overlap. The clock driver circuit looked pretty regular in the layout so I was guessing they might have redundant parallel drivers that could be enabled or disabled by the ROM bits which could change the relative strengths of the two paths, after manufacture. This would allow them to recover the part and improve yield. But I guess edge rates and periods were slow enough then that this was not a concern and just relative sizing was enough.

<comment><USER10> I recently read the book _Principles of Power Integrity for PDN Design_ and it talks about the same problem from a perspective of a board designer. The authors mention that in the vast majority of chips, due to the bond wire inductance alone, board-level bypass is useless at frequencies above 100 MHz. The only solution here is adding on-die capacitance, otherwise it's not possible for a modern chip to operate correctly. In practice, the on-die capacitance is often minimum due to its high cost, only effective at frequencies above 100 MHz, leaving an anti-resonate peak around 100 MHz, thus the problem can never be eliminated (unless a better package or more on-die capacitance is used, which is not implemented due to its costs). And the author showed how you can break almost every power distribution network of a FPGA, by switching logic circuits in code at the exact anti-resonate frequency where bypassing is least effective. Although it's usually not a problem in practice (until you get "lucky"...).

And contrary to popular beliefs, it's impossible to remove it, no matter how many bypass capacitors or how much buried capacitance exists on the circuit board. In a complex chip like FPGA, PDN is critical. The author suggested that the best thing the board designer can do is a workaround: using bypass capacitors of multiple values to "tune" the PDN - this was done as a rule-of- thumb in the old days, and today it's often seen as a bad practice as it creates multiple uncontrolled resonate and anti-resonate frequency spikes when capacitors are combined with parasitic inductance (similar to the case of the 100 MHz peak, but at board level), so at some range of frequencies, impedance is actually significantly increased, which is in conflict of the goal of decreasing PDN impedance at all frequencies. But in the case proposed by the authors, it's done in a controlled manner - the PDN impedance is intentionally increased by carefully creating a flat, slightly higher impedance region around 100 MHz to dampen unwanted oscillation (with simulations and measurements) when it's inadvertently excited.

Also, sometimes changing the timings or operating frequencies is required, so the impedance peak of the chip PDN is not excited, even when it means the end- user must redesign firmware, microcode, or HDL code.

</comment></comment></comment></comment></comment></comment><comment><USER12> It seems noteworthy that clock, Vdd, and Vss trees do not penetrate the microcode array.

<comment><USER2> Note 1 to be specific :-) "The microcode ROM forms a large region with no power connections, just ground. This is because each row in the ROM is implemented as a very large NOR gate with the power pull-up on the right-hand edge. Thus, the ROM gates all have power and ground, even though it looks like the ROM lacks power connections"

The outputs from the microcode go into clocked latches to the left of the array.

The high-level motivation is that you want the microcode ROM to be as dense as possible, so you want to minimize the number of different signals going in there. It is constructed with just the input lines, transistors (or gaps), ground, and the output lines, so it is about as dense as possible. Even so, it takes up a large chunk of the 8086 die.

</comment></comment><comment><USER13> Is it conceivable that the clock signal could supply the power in a CPU?

<comment><USER2> I'm not sure why you would want to power a CPU through the clock. However, microcontrollers can get inadvertently powered through the I/O pin protection diodes if you don't hook up power and ground: [https://www.eevblog.com/2015/12/18/eevblog-831-power-a- micro...](https://www.eevblog.com/2015/12/18/eevblog-831-power-a-micro-with- no-power-pin/)

<comment><USER10> I once spent two days debugging a microcontroller circuit for my retrocomputing project because of this problem.

The microcontroller was an Atmel ATmega328P I extracted from an Arduino board, I used the chip as an external debugger and monitor. The first function I implemented was EEPROM reprogramming via a programming socket, the code was working without any sign of issue for two weeks, working as intended. I could burn a program to the ROM, plug the ROM in the 8-bit computer and execute instructions. Later I attempted to plug the microcontroller into the system bus of my 8-bit computer to add in-system reprogramming and memory debugging capabilities, so I don't have to plug and unplug the ROM every time I need to reprogram it. I planned to implemenet it by taking over the system bus of via DMA, so the running CPU would handover its the control to me. However, no matter how I changed the code, there were always some strange bugs. RAM reading and writing never worked reliably, there's random memory corruption, and the CPU was never able to continue executing the program correctly after the DMA had finished. It seems there were always some forms of bus contention bugs in the microcontroller, as if the GPIOs pins were not properly tristated/isolated before the beginning of a DMA cycle. But I was unable to find it at all in the code.

Eventually I realized the pin 7, Vcc, was not connected! I miswired the power to an I/O pin. From the beginning, the ATmega328P was operating without the main digital power supply and was sourcing all the power via the ESD diode on the I/O pin, and/or possibly the analog power supply AVCC. I was surprised that it was able to work for two weeks. On second thought, during EEPROM programming, the connection to the chip was direct, and tristate was mostly not used, the MCU had no problem driving it. But in memory debugging, the bus is long and the entire output was tristating on and off during a DMA cycle, the lack of a proper Vcc supply probably made the I/O driver to malfunction, especially the input/output selection, creating unpredictable output state.

Later on in another unrelated project, I encountered another problem due to an incorrect PCB footprint pinout. The 4-pin SMD crystal was connected to the wrong pins - only one side was connected to the chip. there's basically no system crystal at all. But the parasitic capacitance between the crystal pins was sufficient to start a weak oscillation (on the oscilloscope you can see a clock waveform with a very low amplitude, it's not at the proper logic level, as if it's an analog RF circuit), the chip was even able to start its 125 MHz PLL! But the logic was not fully functional until I dead-bugged soldering the crystal the correct way.

Lesson learned: Always double check. Just because the chip has power, doesn't mean the chip is receiving power correctly. Just because the chip has a clock output, doesn't mean the chip is receiving the clock correctly. And finally, if there's an external power-on reset, just because the chip was initialized after you apply power, doesn't mean the power-on reset circuit is functional.

<comment><USER14> Reminds me of the history of the ARM1 chip, where the chip was accidently running off leakage alone [1]

[1] [https://en.wikichip.org/wiki/acorn/microarchitectures/arm1](https://en.wikichip.org/wiki/acorn/microarchitectures/arm1)</comment></comment></comment></comment>


Ask HN: (JavaScript): How often have you needed instanceOf and/or isProtoTypeOf? - <AUTHOR>

I'm not questioning the utility of these, I'm just curious how often in day-to-day practice folks end up needing them. <comment><USER2> Most of the time, I consider the use of instanceof as a code smell. You could easily replace the type checking with a polymorphic method call. For example, say you're doing:

if (obj instanceof Foo) obj.doSomething(); else if (obj instanceof Bar) obj.doSomethingElse();

In that case, if it makes sense for Foo and Bar to share a common ancestor, the ideal thing would be to have a doSomething function on the parent class (or parent prototype in javascript), which is overridden in both Foo and Bar, therefore making the type checking unnecessary. Simply call doSomething on the object.

You should note that this is not applicable to every situation, but it should take care of most cases where you would need to use instanceof.

</comment><comment><USER3> I would think that it depends on how structured your code needs to be. For example, I'm working on a soon-to-be open source project which makes heavy use of prototypical inheritance, so I use it a lot. That being said, for one-off projects that do not require a lot of extensibility, you might not use it at all.

</comment><comment><USER4> I've only ever used it to check if a given variable contains an Array. Seems to be the easiest way.</comment>


What is the biggest bootstrapped company? - <AUTHOR>

I'm currently building a business based on a groundbreaking idea in a huge market. It already has some traction.
I wonder how big it can become without raising money.
Are there any examples of companies that became really big while being profitable from day 1? <comment><USER2> Plenty of examples to think about, but I suppose it depends on your definitions of really big:

1\. Atlassian became very large before raising money, Github too 2\. Litmus is a pretty large company, but not Billion dollar club (which is the typical "really big" moniker 3\. Dyn was pretty huge $50M/year+ before they raised money

<comment><AUTHOR> Thanks. If there are any audio interviews/stories out there about these companies, I would love to listen to those.

</comment></comment><comment><USER3> Maybe IKEA? :)</comment>


Free Trade and the Golden Rule of Capitalism (2018) - <AUTHOR> https://rhsfinancial.com/2018/06/06/free-trade-golden-rule/ <comment><USER2> "If necessary, the financial industry can and should save the world..."

Yeesh. No, more influence for the financial industry is not what we need, and more impact of the stock market on political decision makers is not what we need either. Neither has been exactly lacking in recent decades.</comment>


Let's Stop Bashing C - <AUTHOR> http://h2co3.org/blog/index.php/2016/12/01/lets-stop-bashing-c/ <comment><USER2> I could care less about integer division and minor details of syntax, but that's not going to stop me from being grumpy about C's continuing popularity.

Every C program I have ever worked on has been riddled with integer overflows, undefined behavior, buffer overflows and bugs. This was perfectly acceptable for a Vax or a Sun workstation in the 80s, and at forgivable in the mid 90s when plenty of developers still only had 8 MB of RAM and wasted half of that on Netscape Navigator.

But we live in an age of Pwn2Own and ClusterFuzz, where even the tiniest of bugs can be used as step 4 in a 6-step exploit, and where C compilers reserve the right to completely and silently break your program at the faintest whiff of undefined behavior.

I know my limitations: I'm not smart enough to write C code that deals with hostile data off the network. Neither are the authors of 99% of the C code that I've seen, with the possible exceptions of djb and a few OpenBSD contributors. It's long past time to invent and use better systems languages. Choose what you want, but choose something safer.

<comment><USER3> That's an easily correctable problem: learn the living daylights out of programming in assembler, and then C will be like a walk in the park: no more overflows, no more pointer screwups, no more forgetting to free the memory, because you'll know exactly what will happen in the chip and the memory when that code compiles.

You'll even start writing code which relies on integer overflow (rollover from #$ff to #$00 again) because, depending on the situation, it will give you a performance boost, or make the algorithm implementation simpler, or both, and you'll know it.

 _It 's long past time to invent and use better systems languages._

I can't comment on Go, but the textbook examples of Rust and even treatises on the subject from recognized experts in the computer science field (Adam Leventhal) show it to be an utterly overcomplicated language for which there should be a criminal trial and a prison sentence of several decades. Immutables, borrowing, no, I have to stop; my head hurts already, and I'm getting a migraine thinking about solving even the simplest of classic input- output problems with such an overly complicated language. (And my head wants to explode when I compare Rust with AWK for solving input/output problems, the biggest reason why computers were invented.)

So... C, C, and more C, because it's infinitely flexible and simple. I like simple, because simple is smart. Complicated and complex isn't.

Let's all please be humane to one another and stop inventing more languages. We need less languages, not a bazillion variations on the one central task: making the computer do something. And for that, we already have all the languages we could ever want or need, and for the theoretical case where we don't, there is always the almighty assembler, in which exist no limitations as to what one can program with it.

<comment><USER4> > I can't comment on Go, but the textbook examples of Rust and even treatises > on the subject from recognized experts in the computer science field (Adam > Leventhal) show it to be an utterly overcomplicated language for which there > should be a criminal trial and a prison sentence of several decades.

You sure are angry with me for working on a programming language.

<comment><USER5> Yeah I don't get this sort of attitude at all. It seems like a very simple sequence of steps:

1\. Creating something non-trivial in language X, 2. Identifying things that language X made difficult, 3. Brainstorming ways to implement solutions to those issues within a set of acceptable trade-offs, 4. Concluding that some of the brainstormed ideas might actually work, 5. Working really hard to implement and iterate on them.

I can't figure out which step the parent commenter scorns. I guess probably step 2, where they see no pain points to begin with. That's fine, but trying to convince people they haven't felt pain that they have felt is a silly battle. I guess they're actually implying that people who have felt that pain are just not smart enough.

<comment><USER3> No, I'm implying that people are either too egotistical or that they overestimate their insights, or both, when they create a new language. These days it seems like there is a new language every 15 minutes. It's getting to be ridiculous.

And the worst part of it is, no such language covers all problems effectively; they all have flaws in one way or another... so the next guy comes along thinking he can do it better, and just repeats the mistake of his or her predecessor(s).

Instead of realizing that this would just exacerbate the problem, they go ahead and make it worse.

 _I guess they 're actually implying that people who have felt that pain are just not smart enough._

It is extremely difficult to solve a complex problem in a simple manner. One literally has to be a genius with a lifetime of experience and insights from that experience in order to be able to pull that off, and even then, it doesn't always work and requires multiple iterations, and lots and lots of experimentation. Case in point: Go, still a work in progress by exactly such people. That should be instructive, but it seems that it isn't.

<comment><USER5> > And the worst part of it is, no such language covers all problems > effectively; they all have flaws in one way or another...

Which is exactly why you don't try to create a language that covers all problems effectively, you define the problems you'd like to speak to. If you have defined those problems in such a way that they are shared by many people, and if you solve those problems in a way that many people find effective, then you may have created a compelling solution. How does that exacerbate "the problem"?

Honestly, what even is "the problem"? Why does it bother you that there are new languages created? The "literal geniuses" from the Bell Labs era experimented a ton, and that was a great thing then, and remains a great thing now. It's always valuable to point people to prior art, but it makes no sense to bemoan research and experimentation.

<comment><USER3> _Honestly, what even is "the problem"? Why does it bother you that there are new languages created?_

The problem is that new languages have such fatal flaws, that they make the problems they are trying to solve even worse.

The second, and much more serious problem, is that it takes at least ten years to truly master a programming language. Humans only live about 70 years on the average, which means that it is impossible to keep up with every new language that comes out. I mean I live for this stuff, but I would literally have to be chained to the computer my entire life without time for anything else. That is nonsense.

Anybody who thinks they have mastered a computer language in less than ten years is either a genius, or unbelievably egotistical and arrogant; and knowing a whole bunch of computer languages in a perfunctory manner, enough to make one dangerous leads to a really shitty job of sorting out that mess afterwards... that's the problem. My problem, and likely other people's problem.

<comment><USER5> But _you_ don't have to learn all of them... If you think a new language makes the problems its trying to solve even worse, you definitely shouldn't bother with it. But many others may disagree with you, and decide to invest that 10 years in really learning it. There is no problem with this.

What I don't understand about your position is its absolutism. You keep talking about people being egotistical and arrogant, but it seems like you're the only one on this thread being those things, by claiming your subjective opinion as objective fact, and then making ridiculous hyperbolic statements about throwing people in jail based on it. It's not a contradiction for you to personally dislike a language's philosophy and for that language to have been a worthwhile creation and valuable to many people.

Your feelings about different languages are just, like, your opinion man.

<comment><USER3> _But many others may disagree with you, and decide to invest that 10 years in really learning it. There is no problem with this._

Just wait until you invest ten years of your life to master a language, only for everyone else to move on to the next new trend, with you stuck holding the bag.

AngularJS, Rust, and node.js, is it? I can't wait to ask you how you're feeling about all that time you invested into all of those, when all the kids move on to something else and they're no longer popular, for no reason other than the newcomers' ignorance, or because something shinier came along, but didn't actually add any value, just re-implemented the old thing in a worse way.

We can then have a discussion about how you're feeling, having wasted a decade or more of your life away on what will then be perceived irrelevant. That's of course under the (optimistic) assumption that HN is still going to be popular in ten years...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> My complaint against C is that some of the smartest people on the planet use it to write infrastructure that regularly fails catastrophically. If the experts who love it aren't capable of writing correct code, I have no chance whatsoever. Humans just aren't good at the fiddly bits (remembering to free(); not to free() twice; not to use after free(); accidentally adding a second clause to a non-bracketed if expression; how many times to we see these in vulnerability reports?).

C is obviously very powerful. There's no denying that. But it does approximately zero of the things to help programmers that a modern language does. It's not even strongly typed in the usual sense (is there the equivalent of casting void pointers anywhere else?).

Finally, C is slow. Yeah, you read that right. Its main problem is that it has no non-wizardry high level semantics for parallelism. For example, modern languages have map() to say "do this operation on all of these items". In C, you have to write that as "for each item in this collection, do this thing, then the next, then the next, ...". If the compiler is exceptionally smart, it might infer what's going on and help out. But with map(), you're explicitly telling the language "I want all of these things to be done" and it doesn't have to _infer_ anything.

I respect C. It's given us a lot of great stuff. But there's no way I'd willingly start a new project in C today given the alternatives. I am dumb, and given the choice between languages which help me and languages which are basically a small step up from assembler, I'm going with one that gives me a reasonable shot at writing safe, fast, and understandable code.

<comment><USER7> Are there any real world examples (with actual measurement) of languages where map uses hardware parallelisation to be faster than a c loop? Serious question! My impression is, no, outside of something like hadoop.

<comment><USER6> I don't have any off the top of my head, but I used a forking map in Python where the inner call was an image processing operation, and it was approximately #cores faster. I think it'd be enormously dependent on workload: if the inner operation is adding two ints, the gains might be lost in the parallelization overheard.

Map is just one example of a high-level construct that permits faster code, though. A lot of us here have done async IO in C because that was the option we had available to us for doing it, but I'd vastly rather do such stuff in Python (3), Go, or Node where the language itself gives you constructs for describing what you're trying to accomplish.

 _My impression is, no, outside of something like hadoop._

That's a pretty big exclusion, though! We use Hadoop-like stuff on, ahem, sizable quantities of data. That's not exactly an edge case.

</comment></comment></comment><comment><USER8> > Spaces are for the human eye, while braces are for the compiler

and for the editor auto indenter too.

I don't like doing the job of the compiler but this is an exception.

I already wasted more time in a few months of Python by hand aligning and debugging code after I moved it around than it saved time for me by not having to type } or end at the end of the block. Note that Python has a { in most cases: it's a mandatory :

And how about the time lost because of "IndentationError: unexpected indent" when copy-pasting code from the editor to the command line interpreter?

To the point of bashing C, the post is an answer to a very few points of [https://eev.ee/blog/2016/12/01/lets-stop- copying-c/](https://eev.ee/blog/2016/12/01/lets-stop-copying-c/) It's mostly about syntax and it's an interesting read. I particularly like "No hyphens in identifiers"

<comment><USER9> Perhaps C's biggest mistake (at least in terms of syntax) is allowing _fewer_ braces than it could have. Specifically the fact that statements like if and for which allow blocks, they aren't required, so you can end up with code like this:

      if(foo)
         bar; baz;

Which, when you throw in a preprocessor has probably caused more bugs than anything other than out-of-bounds pointer errors.

Of course the fact that everything, including a block, is a single statement is C is one of the things that gave me my first big "whoa" moment when learning to program, and makes me glad that C was the first "real" language I learned (after Basic). K&R C is far more elegant than people give it credit for, probably because modern, real-world C is full of all sorts of weird stuff (and often egregious preprocessor abuse - yes, I'm looking at you PHP), or people learn C++ first and assume it's all the same.

<comment><USER10> Is the above code example, though legal, considered bad practice?

<comment><USER11>
      if (foo)
         bar; baz;

_Is the above code example, though legal, considered bad practice?_

Yes, misleading indentation like this is bad practice for anyone who believes that there is such a thing as "bad practice" exists. For clarity to those who do not know C, the problem is that "baz" is executed unconditionally, even though the formatting misleadingly implies that it depends on "foo".

Unfortunately (in my opinion) there is not consensus on whether the following is bad practice:

      if (foo)
         bar;

My belief is that this formatting should be avoided, to avoid the case where someone not familiar with the rules of C (or not thinking about them) edits it to add a manually indented "baz" on the next line:

      if (foo)
         bar;
         baz;

Personally, I'm fine with a single line without braces:

      if (foo) bar;

But I believe that as soon as the body is moved to another line, braces should be required:

      if (foo) {
         bar;
      }

This belief is common, but not universally shared. Some go farther and say that braces should always be required (there is a good argument for this). Others say that a two line if statement without braces is just fine (I think they are wrong).

<comment><USER10> Thanks for your informative answer.

</comment></comment></comment></comment></comment><comment><USER12> I like this short article for a few reasons:

1\. It makes the case that just because you don't like something, it doesn't mean that there's not a good reason behind it.

2\. Just because you like something, it doesn't mean that it is good (or bad).

3\. The things that the naysayers constantly bring up just aren't really that bad to begin with.

C is amazingly powerful, and I love it. I love JavaScript, too (especially since ES6!), but I don't confuse where I should use one rather than the other. I tolerate Python. ;)

Languages are just tools, and you should use the one most appropriate for the job at hand.

<comment><USER13> Tools should be ergonomic and should have guards and other safety mechanisms to make it easy to do what you intend to do, and difficult to do things that you do not intend to do. C tends to do the opposite of that. It makes certain things that you want to do more difficult than necessary, while making it very easy to do things that no reasonable person would intend to do. Evee's original post highlights that.

In fact, if you look at this post, some of the so-called defenses seem more like indictments to me. For example, in the increment/decrement section, there is this:

 _But look, there's an even more direct argument: the ++ and -- operators are not even "one" operator. There is a prefix and a postfix variation of them that do slightly different things. The usual semantics is that the prefix ones evaulate to the already-modified expression, while postfix ones yield the original value. This can be very convenient, as in different contexts, code might require the value of one state or another, so having both versions can lead to more concise code and less off-by-one errors. Therefore, one can't simply say that "++ is equivalent to += 1", as it is simply not true: it's not equivalent to at least one of them. In particular, in C, it's not equivalent with the postfix increment operator._

This illustrates exactly the point that Evee was trying to make. It's hard enough to justify having increment and decrement as their own operators (as opposed to a performance optimization implemented by the compiler). Having two variants, which work exactly the same in the vast majority of instances, but do subtly different things in e.g. if-statements and for-loops is complete and utter madness.

<comment><USER14> I really disagree that this is madness. It may be madness to someone not used to coding in C. But if you code a lot of C you _will_ know when to use which one of these, and you will know that they're immensely useful.

For example, iterating and adding stuff to arrays:

array[index++] = object;

instead of

array[index] = object; index += 1;

and the other way around:

array[++index] = object;

instead of:

index += 1; array[index] = object;

There is no way you will miss incrementing your index here, or do it in the wrong place. This is so common, that as a C-programmer you WILL recognize this pattern.

It's even better when iterating pointers instead of integers. May I ask what the following means to you?

float *float_ptr; float_ptr += 1;

I think writing ++float_ptr here is just much more clear. Incrementing pointers by integers just feels wrong when what you really are doing is incrementing it with sizeof(float_ptr).

<comment><USER15> Until the logic is complex enough and you screw it up. Then you write over '\0' in some string and have a root exploit. Congratulations!

float *float_ptr; float_ptr += 1;

is no more confusing than

float float_ptr[...]; float_ptr[1];

</comment></comment></comment></comment><comment><USER16> Even more important, let's stop seeing bash.

If somebody had set out to create a language prone to error and exploitation, bash would result. (It's fine for interactive use BTW, just not as a language in which to write anything complex or long-lived.) While it might not have C's pointer/memory problems, its lack of real types or scope rules and its other idiosyncrasies (e.g. making it nearly impossible to distinguish "" from an undefined variable or the whole $*/$@ mess) make it even more of a nightmare. I've actually gotten pretty handy with it because I had to, but it's a far worse crime against developer sanity than C ever was.

<comment><USER17> Totally agree! By the way, the Haskell community is working to make scripting easier in Haskell, so if you want to go from one of the most buggy languages straight to one of the least, now you can: [https://docs.haskellstack.org/en/stable/GUIDE/#script- interp...](https://docs.haskellstack.org/en/stable/GUIDE/#script-interpreter)

(Downsides: Haskell is weird (but good), you have to have Stack installed, and the first time you run the script it will take a while to download dependencies)

More resources: [https://github.com/Gabriel439/post- rfc/blob/master/sotu.md#s...](https://github.com/Gabriel439/post- rfc/blob/master/sotu.md#scripting--command-line-applications)

</comment></comment><comment><USER18> Hating C because it has integer division is like hating haskell because it is functional. It is inherently low level. C's real problem is that is has undefined behavior in a lot of cases. C with some kind of compile-time memory protection and no undefined behavior (so basically Rust) would be a pretty sweet systems programming language.

</comment><comment><USER19> I do wonder whether this might have missed the point.

"Let's Stop Copying C" isn't a criticism of C, so much as a criticism of other languages that have applied a kind of conceptual copy-paste of C-like characteristics.

Demonstrating that there are good reasons for those characteristics to exist in C talks entirely past the question of whether the sharp edges of some of those characteristics are still warranted in other languages with other design goals.

<comment><USER20> The author completely missed the point. It is pretty clear in the Eevee's post (hell, it is even in title) that she isn't saying that C is bad per see, however she thinks that modern higher level languages copying C design parts is silly because it really is. Heck, Java has a god dammit reserved goto keyword for the sake of it.

For sure, the author takes the most controversy points of Eevee's points, that AFAIK are mostly (her) personal preferences. However it does not enter in the interesting parts of her argument, like weak typing, C-style loops* or textual inclusion.

This post was much less interesting read than Eevee's post, that makes me wonder if the author did a click-baiting title just to try to get some clicks on his blog following Eevee's post...

*: really, this is the most retarded thing of the whole C-family languages; it kinda makes sense in C, however if you're writing a modern language that only supports this kinda of loop (pre-ES6 Javascript comes in mind), you're retarded.

</comment></comment><comment><USER21> Interesting list of things to bash C and Algol-derived languages on. I really like Eevee's original approach of doing a comparative survey rather than talking about things in isolation. ( [https://eev.ee/blog/2016/12/01/lets- stop-copying-c/](https://eev.ee/blog/2016/12/01/lets-stop-copying-c/) )

Point by point:

\- textual inclusion and macros: yeah, this technology was obviously chosen for ease of implementation on small systems and makes little sense. Now obsolete and a handicap. Especially in C++.

\- optional block delimiters: responsible for gotofail and similar errors.

\- modulo: symptom of C not having standardised maths semantics. Standardise your semantics, language designers! Don't just say "whatever the CPU gives us, I'm sure it'll be fine".

\- octal: Nobody uses goddam octal and it's a trap for people used to leading zeroes in decimal.

If we're changing this then I'd like to appeal for some features from Verilog e.g. 8'b1101_1101 : leading width specifier, and the internal underscore which is ignored but provides visual clarity.

\- power operator: meh.

\- switch: actual operation is kind of bananas, see Duff's device. Should be block-based.

\- integer division: Careful. Huge argument here about maths.

(tbc)

<comment><USER22> > \- octal: Nobody uses goddam octal and it's a trap for people used to > leading zeroes in decimal.

0b..., 0x..., 0o... the latter is still a bit subtle (0Oo), but far more distinct and far less likely to happen by accident.

> \- switch: actual operation is kind of bananas, see Duff's device. Should be > block-based.

the goto-table semantics of switch are kinda useful in many instances, OTOH a compiler should be smart enough today to achieve the same degree of rather simple optimization.

</comment></comment><comment><USER23> Writing performant interpreters is _really hard_. People wrote those performant interpreters in C because it was necessary. Rather than blog about what's wrong with C or C++, why not write re-write your Python or Ruby interpreter in Rust/Swift/Whatever - that should _really_ show us dinosaur C/C++ programmers that we were wrong all along.

PS: it's not as easy as you might imagine.

<comment><USER24> The original blog didn't blog about what was wrong with C or C++. It blogged about other languages blindly picking up design decisions from C even though they don't really have a reason to.

And Rust has been consistently delivering software with performance on par with or faster than C counter parts. [http://blog.burntsushi.net/ripgrep/](http://blog.burntsushi.net/ripgrep/) is a recent example. Servo is a more long term one.

</comment></comment><comment><USER25> Weak arguments.

Integer division _is_ misleading. It uses the mathematical division operator for something that doesn't behave in that way. Having a separate 'integer division' operator (e.g. //) is much clearer.

Nobody could say that the pre/post increment aren't confusing. They feature heavily in 'trick question' C++ tests (along with undefined behaviour, type promotion and so on).

<comment><USER26> > It uses the mathematical division operator for something that doesn't behave > in that way.

Floating point does not behave in a mathematical way, either.[1][2] Unless your language uses fractional representation using big integers for real numbers.

> that the pre/post increment aren't confusing

The operator and retrieval of the variable are two separate operations that occur in the order that you read them. None less trivial than "I" before "E" except after "C".

[1]: [https://en.wikipedia.org/wiki/Single-precision_floating- poin...](https://en.wikipedia.org/wiki/Single-precision_floating-point_format) [2]: [https://en.wikipedia.org/wiki/Arithmetic_underflow](https://en.wikipedia.org/wiki/Arithmetic_underflow)

<comment><USER25> > Floating point does not behave in a mathematical way

It approximately does. The only common way that newbies would get tripped up is something like (3 * 1/3) != 3. Maybe that is a case for not allowing == operator to operate on floats (use a function/keyword instead), but I think that may be a step too far.

<comment><USER27> I don't think that is a step too far. When I was writing embedded code, == and != were prohibited for floating-point values. I support such a rule in general.

<comment><USER28> Years ago, I worked on software that dealt with computational geometry a lot, and I quickly found out the hard way that the equality operator is pretty much useless for floating point values.

On the other hand, that is a property of floating point numbers, regardless of what language one uses.

<comment><USER29> > On the other hand, that is a property of floating point numbers, regardless > of what language one uses.

That's true, but, OTOH, having floating point rather than an exact representation be the default representation for values represented as decimal literals, and the only non-integer type supported by convenient operators is a language-specific "feature" of C that many other languages don't share. (Though, to be fair, there are also many newer and popular languages that do share both, and more just the first, of those features.)

</comment></comment></comment></comment></comment></comment><comment><USER30> C really is still a beautiful language.

<comment><USER31> I like the language itself, I just dread the tooling around it. If there would be a better build system, easier integration of libraries, better strings and an overhauled standard library I would start to use it again.

<comment><USER32> It struck me during the "Modern C" discussion a day or two ago that C would be very well-served by a good package and build system with dependency management (akin to npm, cargo, cpanm, gem, etc.). While there are some pathological cases (npm, with it's insanely long dependency graphs...I once installed a small package that pulled in 53,000 files in dependencies), the value of a massive standard library that everybody is using, contributing to, and testing, is just incredibly valuable. There's a gazillion lines of C code out there, but finding/using/distributing it can be tricky. If it's not part of the standard OS distribution, in particular.

Make, while I quite liked it in its day, has some real limitations. cmake, while better on some fronts, doesn't actually solve the right set of problems (or, it solves the set of problems as they were perceived ~15 years ago).

I wish there were a strict subset of C (compliant with standards, but that prohibits the trickiest bits during build), with a good package/build system, a huge/modern library of high level functionality. I always enjoyed poking at C, but I just can't spend enough time coding in C to ever be really good at it. I can go years between working on C code, so I forget all the gotchas by the time I look at it again. It's not forgiving of casual users the way Ruby, Perl, Python, Go, and even (some) Java can be.

Then again, I guess Go is kinda that language for some classes of problem (not the very lowest level systems stuff, but I rarely do any of that kind of coding, anyway; I haven't touched a kernel module in a decade).

<comment><USER31> > a good package and build system with dependency management (akin to npm, > cargo, cpanm, gem, etc.)

In most cases I don't even need a full build system. I do most of my hacking in Python and I often create small "throwaway libraries" to create a nicer structure of my project. In Python you can do this by just creating a sub- directory and a __init__.py file. This takes 45 seconds and then you can easily "import lib_xyz" in your project. And if you need this library in another project you can just copy/paste the. (I know, this is not an ideal solution but when I am hacking on some stuff it is a good way to do things because it takes no effort and brainpower to do it)

<comment><USER32> You can whip up a makefile in seconds to do simple stuff, too. That's not the problem I'm talking about; it's not that make is _hard_ , it's that it is incomplete (and kinda hard, for advanced stuff).

</comment></comment></comment></comment></comment><comment><USER33> Bashing C is like bashing English. Well, maybe Tolkien Elvish might have a better grammar system, but really come on now.

<comment><USER34> Natural languages and programming languages aren't really comparable. The former evolve and are beholden to their history, because you can't tell people how to speak. The latter are user interfaces, and to suggest that the only meaningful criterion in user interface design is that it should match what previous designers have done is just self-evidently silly.

<comment><USER35> > The former evolve and are beholden to their history, because you can't tell > people how to speak

Think about that for a moment in the light of Python 2 - Python 3 or K&R C - C99 or original C++ - C++14

<comment><USER34> "The former" refers to natural languages, not programming languages. What you cite is one of the primary reasons I called the two classes incomparable. If programming languages worked like natural languages do, Python 3 wouldn't have been controversial, or exist.

</comment></comment></comment></comment><comment><USER36> From the original article: " Which is why we still, today, have extremely popular languages maintaining compatibility with a language from 1969 — so old that it probably couldn't get a programming job."

Yikes! How about "old enough to have a crapton of experience I'd really like to learn from/integrate with my company"? I know there is ageism in this industry (towards both people and tools), but sometimes the cavalierness with which people throw out the idea that "old == bad" and "good == new" comes as a shock.

And besides that, shouldn't we be _proud_ of half a century of stability and compatability? Isn't "well-designed systems that stand the test of time" a holy grail to reach for, rather than poke fun at?

</comment><comment><USER37> Are people actually boggled by the "++" operator? If they can barely wrap their minds around that, why are they even in programming? Seriously!

<comment><USER38> There are two typical use cases for `++` and they should be considered separatly.

Firstly there is simply the `i++`, which is redundant with `i+=1`, but it's also very easy to understand syntactic sugar. Keep it or leave it, no big deal.

Then there is the more advanced and very subtle use of the return value:

      int i = 3;
      while (i--) {
          printf("%d, ", i);    // What does this print?
      }

This one is very controvertial. On one side, it simplifies and shortens code by a lot, but it also makes the code say too much at the same time. Can you tell by glance what this code would do? Personally, I prefer longer code and more expressive code, but I can also cut corners with the short version from time to time, when quickly testing something out.

EDIT: Fixed code formatting

<comment><USER39> I'm glad it's the first time I see that code, instead of a usual for loop.

It doesn't compile in C++. Conditions have to be booleans. i-- is an integer :D

In C, 'true' is defined as anything else than '0', there is no proper boolean types, i-- is an integer which is perfectly okay for conditions, the condition is equivalent "while (i != 0)".

There might be some variations, errors and warnings depending on the compilers, the strictness level and the revision of the language chosen.

<comment><USER40> This is completely false, it compiles in C++ fine. Are you thinking of Java?

<comment><USER39> Well, it shouldn't. It's possible that you have to give a flag to the compiler to error on that kind of implicit casting. It should at least give a warning for sure.

I am definitely talking about C++

<comment><USER41> Compiles fine with -Wall -Werror. No warnings.

<comment><USER39>
        int x = 1;
        bool y = x;

        # cl.exe /W3 main.c

This code gives a warning on VS2012. But it doesn't give one when the cast is in a loop condition. That is weird.

[http://stackoverflow.com/a/31552168/5994461](http://stackoverflow.com/a/31552168/5994461)

This stackoverflow message talks about the specs for C11, and the first comment adds information on the C++03 spec. It seems that implicit cast from integer to boolean is allowed... under all circumstances... depending on what specification the compiler is following :D

For future references, I'll just summarize this as "C and C++ are minefields". We'll just add that to the list of WTF behaviors.

By the way, if you think that "C has had bool for 19 years" [the C99 spec specifically]. You clearly didn't work in C for long enough with a large variety of tools. The world is bigger than just GCC.

<comment><USER40> > But it doesn't give one when the cast is in a loop condition. That is weird.

I believe that the justification for that is that you'll often want to do e.g.

        while (node) {
          node.val += 3;
          node = node->next;
        }

Implicit conversion of a type into a bool is pretty useful here, or for e.g.

        while (std::cin >> x >> y) { ... }

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> Some of the issues defended here can be resolved if operator overloading weren't so prevalent.

"++ is also used for iterators" Python has "next". I understand there's "*p++", but the semantics of ++'ing an integer or ++'ing an iterator are very different! Why should they share the same mechanism? (There's an argument that ++ on integers is iterating over N. Pedantically true)

"Integer math is useful!" Floating point semantics are different, so why not use different operators for such? Caml has + for its, +. for floats. Impossible to mix different semantics together implicitly.

\--

I find saying "whitespace sensitivity makes auto-indentation impossible" to be a bit silly. The equivalent of auto-indentation in Python to C is auto-brace insertion! Just as impossible.

There are definitely parsing difficulties with whitespace sensitive language (technocally, lexing difficulties). If you're willing to go for parenthetic function calls like in Python, it's not too hard. But go for Haskell-like function application and you're in for a treat! Would not want to have to parse Scala.

I can see the argument to braces being better, though. It's such a subject of taste that if you don't want to be opinionated, going for explicit blocks is really your only choice.

</comment><comment><USER24> > What's Wrong with Increment/Decrement?

This sort of misses the point there. What eevee was saying was that "Usually you use ++ to mean +=1". It _is_ equivalent to +=1 in those cases.

Eevee then goes on to say "The only difference is that people can do stupid unreadable tricks with ++.". She _is_ talking about postfix/prefix there. She never said that ++ and += are _exactly_ the same, she's saying that they're mostly the same, except for some cases which often read to more unreadable code. Using i++ or ++i as an expression within a larger expression often leads to unreadable code.

The author here then goes on to talk of off by one errors, but ++-as- expression is what _causes_ a lot of off by one errors.

[https://news.ycombinator.com/item?id=13089663](https://news.ycombinator.com/item?id=13089663) explains this a bit too.

\---

The other two points also miss the point a bit. The post is not "why C is bad". The post is "Let's stop copying C". There are good reasons behind C having many of these features. These reasons do not necessarily port to other languages; yet they copy the feature.

</comment><comment><USER43> In college (over 10 years ago) I used to think C was very viable. Sure it took longer to develop but the reward was fast execution and generally KISS like code (just an anecdotal observation I have of C is the tedium to write complex things forces simpler solutions... I mean who wants to malloc over and over).

But near the end of college I had to write code using pthreads. It was awful. It was exceedingly painful. Banging on the keyboard cussing continuously painful.

Maybe it was just pthreads (I'm sure there are nicer libraries) or my stupidity but that exercise killed my mild liking of C.

Languages I like are heavily expression based but don't require braces (algol like languages) nor parenthesis (lisp like). As much I dislike braces and parenthesis (for blocks) I despise statement heavy languages more (sadly python). I wish the article of the "Stop Copying C" mentioned that (or maybe I only share that opinion).

<comment><USER23> > But near the end of college I had to write code using pthreads. It was > awful.

For what it's worth, I don't think it's C's pthread library that is painful, but POSIX threading in general. Languages and libraries try to "simplify" threading by re-inventing pthreads. Eg: python's 'threading' module, erlang in general, java 'runnable' interface, golang's 'coroutine' thread manager...etc.

The difference between all those languages specific threading implementation and POSIX threads, are that POSIX threads work across _every_ language, and all those implementations are only relevant to the language itself. Working with "one size fits all"(pthread) tools is inherently more complex than a simplified tool specific to one language.

Summary: once you learn POSIX threading [well] in C, using other pthread abstractions in other languages becomes much easier.

<comment><USER43> If I recall it wasn't that I didn't understand the concepts but rather difficulty in debugging. At the time I was ignorant and ill experienced of proper tooling. Today when dealing with C I would probably not even bother with using threads and might just use multiple processes.

I agree on the reimplementing POSIX threading and despite my rough experience pthreads was worthwhile learning about.

</comment></comment></comment><comment><USER44> I 100% agree with this article. I'm a student that has learned Python, Java and C - using each depending on what I need to do.

Having taught as well, Python is not a language for beginners. They are punished for getting their spacing wrong, often confuse types, oo seems to have been an after thought and versions 2 & 3 are completely different languages.

C can also be confusing for beginners, but not for the reasons mentioned. Teaching people about pointers spins heads for the first time.

Java for me seems to be the middle ground. Good understanding of oo, portable code, solid types, well formed errors, beautiful garbage collection and well thought out (libraries, types, access, concurrency, etc).

C is obviously an advanced language, but like PHP there is a good reason why it's not ready to be buried yet.

<comment><USER30> One of the things (among many) that _does_ make python a good language for beginners is its short developer feedback loop. The pleasure of programming is important, so even if they're writing terrible code at first, there's a strong motivation to keep going. Along the way their skills develop.

<comment><USER44> I agree, but this is achievable in other languages in the same way it is for Python - simply output something interesting via a package or library. First practical we have students drawing shapes in Java and crudely animating them.

</comment></comment></comment><comment><USER45> Regarding integer division, the Wikipedia article about modulo operation has nice graphics.

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

</comment><comment><USER46> Is there any room for a form of C with immutable semantics which forced you to jump through special hoops to get mutable data access (solely for performance reasons)... Or does Rust basically have this design goal already?

The limitation of programming (from a bug-minimization perspective) is the programmer's ability to understand all the possible states his code and data can get into which means that the key to bug and security hole elimination is any pattern which reduces cognitive load

<comment><USER47> I'm struggling to understand how requiring explicit mutability has anything to do with performance or "hoops."

I mean, getting mutable access is trivial:

      let mut x = ...
      fn frobnicate(x: &mut...)

The performance "problems" in Rust requiring "hoops" are in very narrow applications (e.g. certain applications of high performance numerical computing). I'm not a fan of the "unsafe-offset" idiom required so that every time access into a vector occurs doesn't waste cycles on a pointless boundary check (for example).

But I must say for a given chunk of Rust code the equivalent C++ code is generally more bloated, because unless you're writing code begging for abuse you're going to have "const" and move operations everywhere, which is sort of inverted from Rust's model.

<comment><USER48> Bounds checks are often elided, so many access of vectors won't waste cycles on pointless checks. Or at least, if they are truly pointless, and they're not elided, that's an LLVM bug.

</comment></comment></comment><comment><USER49> > The only thing I can suggest you to do is to actually go program in C for > some years, write some good software, and you will see what I mean.

(from the OP's comments to another reader)

Allow me to translate: Ok, let's stop bashing C. Let's start bashing people who have legit complaints about C.

I don't think the above comment was warranted. Someone took the time to read your arbitrary article and attempt to offer a meaningful point and your response was to demean the fellow.

</comment><comment><USER50> And of course engineers and architects are blameless on this - we would not allow for gradual replacement, no, Sir , we need a revolution, tear down this Wall and build a brand new Castle in the sky. Nobody wants to weld new things to a rusty Compiler, until the Compiler is all rusty, but still fully able to bind all the legac inertia factor to his will.

</comment><comment><USER51> I've always been a huge fan of the increment and decrement operators. I don't use them all the time, but they're very nice to have on occasion, and with operator overloading they can be made incredibly useful. I thought it was a very silly decision for Swift to remove them.

<comment><USER52> Here are some reasons that Python removed them: [http://stackoverflow.com/questions/1485841/behaviour-of- incr...](http://stackoverflow.com/questions/1485841/behaviour-of-increment- and-decrement-operators-in-python)

Edit: a nice write up by Chris Lattner: [https://github.com/apple/swift- evolution/blob/master/proposa...](https://github.com/apple/swift- evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md)

<comment><USER53> It's very unfortunate that attempting to use preincrement and postincrement operators in Python results not in a syntax error, but in code that silently does something very unexpected.

</comment></comment></comment><comment><USER54> I've seen these pixels before. C is a permanent fixture. It is not going anywhere in your lifetime. You can use it, or not.

[http://www.joshianlindsay.com/index.php?id=170](http://www.joshianlindsay.com/index.php?id=170)

</comment><comment><USER55> Given that the original article that this replies to starts with "It [C] works well for what it is, and what it is is a relatively simple layer of indirection atop assembly." I'm not sure "bashing" is an exactly accurate.

Given that this reply also starts with "To begin with, I agree with most of the things Eevee wrote", I'm not sure "Let's stop X" is the right title to use, even if it matches the theme of the original article.

The reply itself is... a decent alternative viewpoint, to a few of the points made, but I don't think it quite matches the title. And now some counter- counter points:

> What's Wrong with Integer Division?

This is the wrong question. The right question is: What's wrong with integer division _if and only if both arguments are integers, and ambiguously conflated with floating point division in syntax_? I'm sufficiently used to it to not find it a big deal, but that's a poor argument for it's merits in new languages.

Nobody thinks integer division shouldn't be _an option_.

> However, the behavior of integer division is very useful. I would argue that > in most cases, one expects it to behave just as it does.

I've seen even professionals trip up over the semantics of this just regularly enough to be annoying - you read float a = x/y; and assume terrible things about x and y, things that were perhaps even once true. Even if you really did intend to round, you probably assumed unsigned 'round down towards zero' semantics and will have a bug to contend with when x<0 and end up rounding up towards zero.

Personally, I haven't found it that difficult to adjust to languages that have a separate integer division operator, or languages requiring an explicit rounding operation, despite a long history of only using languages with C's semantics before them.

> Unfortunately, Eevee seems to fall for the extremely common "++ is > equivalent with += 1" fallacy. You can see it's a fallacious statement when, > in the end, even the author herself admits that there are things that can't > be implemented in terms of "+= 1"; for instance, incrementing non-random- > access iterators.

That Eevee herself points out that "++" is not always "+= 1" makes it quite clear that she hasn't "fallen" for any such fallacy. The point is that even including other unmentioned (ab)uses of overloading, there _is_ always a way to rewrite things in an equivalent manner in terms of "+=", "-=", or custom functions - _combined with_ either the abuse of the comma operator, or multiple statements. For the mentioned case of iteration - plenty of other languages have a separate, named function for iteration, even if they allow "++" and "\--" to be overloaded.

The only real point of debate here is how often the "++" and "\--" operators produce _concise_ code, versus how often they produce _write-only_ code.

</comment><comment><USER56> It seems to me that a lot of issues could be better handled if we weren't limited to programming in a subset of the ASCII char set. Unfortunately, the alternative is to completely retool the modern keyboard.

<comment><USER57> We've already been down that road:

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

</comment></comment><comment><USER50> Only if C stops bashing us first- it started it.

</comment><comment><USER58> I will stop bashing C when C code looks as beautiful as Python code.

<comment><USER59> Of all the problems C has, looking ugly isn't one of them, and most of the ugliness would be done away with if the language adopted a proper module system and C++ "constexpr". The Linux kernel in particular is quite nice to look at: [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel?id=v4.9-rc7)

</comment></comment><comment><USER60> Let's stop bashing bashing.

<comment><USER61> Is prefer to keep bashing bash, if possible.

<comment><USER50> Hey, dont mock the wailing parade around the C-monument. This must be its 300 cycle and its still growing strong.

Helping the inertia by self-sabotaging with over idealistic , non backwards compatible languages, the software architects and computer scientists lead the procession.

Followed they are by self-flagellating programmers, trying to figure out who beat them to it again and again.

Followed they are by the silent businessman parade, who search for the perfect compromise between throw-away code and reuse ability on hardware where the solder-lead is not stable yet.

All hail the holy C, all hail the mighty procession of pain.</comment></comment></comment>


Beyoncé's Parkwood Entertainment sued over website accessibility - <AUTHOR> https://www.theguardian.com/music/2019/jan/04/beyonce-parkwood-entertainment-sued-over-website-accessibility <comment><USER2> Is there precedence for such a lawsuit?

I've wondered about legal obligations to web accessibility in the past and assumed it would eventually become a bigger issue since.

<comment><USER3> My previous understanding was that these kinds of web accessibility lawsuits and fines were relegated to government web services and vendors, both those for external and internal use. Seems that there is a broadening interpretation of the ADA due to the increasing ubiquity and essential utility of e-commerce.</comment></comment>


Did glitch help Amazon escape early questions in Washington hearing? - <AUTHOR> https://www.reuters.com/article/us-usa-tech-congress-glitches/did-glitch-help-amazon-escape-early-questions-in-washington-hearing-idUSKCN24U361 <comment><USER2> Weird and sad to see Reuter's using such a clickbaity headline

<comment><USER3> Am I missing something? It seems like a good description to me. If you're referring to the fact that it's a question, normally that's clickbait because the article answers the question, but in this case it doesn't/can't.

<comment><USER2> I'm referring to the fact that the title makes it sound like something nefarious and as always you can answer any headline that's a question with the answer - no.</comment></comment></comment>


Student loan programs are too expensive to forgive - <AUTHOR> https://fivethirtyeight.com/features/student-loans-are-too-expensive-to-forgive/ <comment><USER2> My first thought on student loans is this: Why can't I as a retail investor get a taste of that federally guaranteed 7% return?

Oh right, because it's a racket meant to favor insiders who are already fabulously wealthy. It must be nice to be so rich that you can make it effectively illegal for anything to make you less rich or even to make you get more rich more slowly.

</comment><comment><USER3> The debt isn't forgiven, the private companies that made the loans are paid by the feds. These programs are windfalls for banks that make what would otherwise be highly-speculative loans. There is a large economic incentive for students to take out loans they'll never repay and shift the burden onto the tax payer.

If universities were 'loaning' the tuition money to students directly, that perhaps could be 'forgiven' as no money has actually changed hands.

The whole system needs an overhaul, same with secondary education. Make the education free to all by eliminating the 'nice to haves' and focus on the 'need to haves.'

<comment><USER4> And then they could directly change their acceptance criteria and drop degree programs that don't match students with decent jobs. I don't say good jobs, just decent ones where they could get by not having to kill themselves and still afford the loans.

</comment></comment><comment><USER5> I mean this will force salaries to increase to attract workers b/c they won't have loan forgiveness as an implicit benefit. This will also reduce workers in those occupations driving wages even higher. That or the non-profit/gov't agencies will have to go without (and maybe that's the reason for this effort). It may also cause schools to drop tuition or make it easier for rich people to get into schools since there will be less competition.

</comment><comment><USER6> No it isn't. See [http://www.levyinstitute.org/publications/the- macroeconomic-...](http://www.levyinstitute.org/publications/the- macroeconomic-effects-of-student-debt-cancellation)

<comment><USER7> A fellow MMTer!

</comment></comment><comment><USER8> If they do that they should put bankruptcy back on the table.

I find it ridiculous that someone can't file bankruptcy for student loans.</comment>


Stanford expels student admitted with falsified sailing credentials - <AUTHOR> https://www.stanforddaily.com/2019/04/07/stanford-expels-student-admitted-with-falsified-sailing-credentials/ <comment><USER2> A step in the right direction but hope universities could undo some damage by admitting students who were previously rejected/waitlisted because they were not "qualified" (ironically). Systematic cheating has always been there as long as there is profit involved, but I am still extremely sad that it got its way into all these so-called prestigious institutes...

<comment><USER3> Brief anecdote as potentially one of those rejected students who was not "qualified":

The community college I went to has a special program with Stanford where the faculty of the CC will, on a VERY rare occasion, nominate a student they feel is mature, smart, and driven enough to a research program they collaborate on.

From my knowledge, every student who has gone into this program has gotten into Stanford.

My transfer application was rejected 2 years in a row, so I was very honored when, during the fall in which I had moved to NY for the school I accepted admissions to, I received an email inviting me to the program.

I was also a bit frustrated, as you can imagine. So, my response was along the lines of "thank you so much for this opportunity, but I'm not so sure commuting 5000 miles each week is practical. Please let another qualified applicant take my place."

A little more context: I had been at the CC for 6 years. The first 2 I almost flunked out, but I turned that around into getting A's and being on the dean's list every quarter. However, averaging 2 years of failed grades meant it would take insanely long to get into the high 3.x's. But my history showed a complete turnaround and ambitious drive towards a goal.

The fall a year later I received another email inviting me to the program. The CC faculty were so used to having me around they just assumed I was still on campus (several wrote me recommendation letters and I'm pretty sure I told them I was transferring).

I responded in a similar fashion as I did the year prior, and then I proceeded to start the PhD program early at my university.

My family doesn't have lots of money or connections. I was never a stellar student (until that 3rd year at the CC and beyond) but I excelled at whatever I set my sights on. I'm glad I went where I did. I did some really awesome things, met some phenomenal people, and united with my better half. However, same as the job search, I've always wondered if my potential place was taken by someone who cheated, made themselves look legit especially when they weren't, or otherwise finagled their way in.

I know I couldn't do it. That's why I stopped playing sports competitively. The cheating was ridiculous and it was worse that the refs stood by it. I want to be excellent and deserve that spot, not mediocre but dressed to look excellent and getting that spot.

If those getting into top schools include cheaters, the likes of which have come to light in the past weeks, then those people are going to get the credibility from having that institution associated with them, the network from being there, and so much more that benefits them and validates the lived lie.

<comment><USER2> thanks for sharing. My own "prestigious" alma mater has been involved in the scandal and I'm really worried the kind of message it sends to younger generations...that money can move mountains and hard-work does not matter...

</comment></comment></comment><comment><USER4> They are only doing this because of the optics. If they really cared, they would go back in history and pull all the degrees handed to people that cheated their way in.</comment>


Passing the test and failing the interview - <AUTHOR> http://rachelbythebay.com/w/2012/11/04/test/ <comment><USER2> A police department in Connecticut rejected candidates who scored too high on an IQ test: <http://abcnews.go.com/US/story?id=95836></comment>


Google: "Android is the Linux desktop dream come true" - <AUTHOR> http://derstandard.at/1308186313932/Interview-Google-Android-is-the-Linux-desktop-dream-come-true?linux <comment><USER2> " _A platform controlled by a single vendor and locked down by hardware vendors != the Linux desktop "dream come true"_ "

<http://twitter.com/#!/segphault/status/90546480737296384>

<comment><USER3> There are a lot of dreams out there for Linux. One of those dreams is an easy to use tablet that's fast, has a lot of apps and is easy to use. That dream has been realised.

<comment><USER4> you mean an ipad??

<comment><USER5> If you've gotten Linux on your iPad, tell me how. Now.

</comment></comment></comment></comment><comment><USER6> I am writing this on an android tablet, best buy so far this year. And fwiw, Ubuntu is the dream come true, not android.

</comment><comment><USER7> FTA:

 _> derStandard.at: How does a company like Google balance the need between wanting secrecy on new developments and doing it open source?

Chris DiBona: That varies between project. If you look at Chrome, every commit is instantly online. Android has a punctuated release model based on its marketing needs.

derStandard.at: Why is the chosen model for Android and Chrome so fundamentally different?

Chris DiBona: It's a different kind of market. If you look at Android we have lots of partners. We have chipset partners, we have handset partners, we have carrier partners. They all want to use Android and they all want to have something special about themselves. So they want to use Android for that specialness. What that means is that one handset vendor probably doesn't want to interact too much with the other handset vendors because they are competitors. And Android gets caught in the middle of all of this. And the bigger question then becomes how you architect software that it's still useful around that kind of model._

He doesn't really say why Android development needs to be secret. So much for openess.

<comment><USER8> _He doesn't really say why Android development needs to be secret. So much for openess._

I thought this was a pretty direct response:

 _What that means is that one handset vendor probably doesn't want to interact too much with the other handset vendors because they are competitors. And Android gets caught in the middle of all of this._

ie - the handset vendors want to keep things secret from each other (and they could gain a lot of information if they saw the commits as they happened on Android). No surprise there, right?

<comment><USER7> _> the handset vendors want to keep things secret from each other_

 _> and they could gain a lot of information if they saw the commits as they happened on Android_

These two statements contradict each other. All handset makers are using the same Android code with some changes. The Android 2.3 in Sony Ericsson is same as the one in Samsung or HTC. Or is Google developing separate Android OSes with each hardware vendor? My question is what's stopping Google from releasing the base Android OS? And what's stopping them from following a open development model like chromium?

Sure MS/Apple/HP/RIM can gain some insight if they saw the commits but that's another matter.

<comment><USER8> _My question is what's stopping Google from releasing the base Android OS?_

Ignoring Honeycomb, they do that - they just delay it. I thought the delay is what you were talking about.

 _Or is Google developing separate Android OSes with each hardware vendor?_

It's not an either/or question. Each vendor has different drivers (for things like different kinds of screens, 3D cameras etc), and if other vendors saw these it would give away their capabilities early.

I believe that each vendor doesn't get to see the whole tree until there is a complete release.

 _And what's stopping them from following a open development model like chromium?_

Chromium doesn't have tight hardware integration.

A better example is something like the graphics drivers in the Linux kernel. Nvidia & ATI have historically been very reluctant to release the code for them and have tried to avoid it in various ways.

Handset vendors have the same motivations as the video card vendors, and so Google has to accommodate them somewhat to get them to use Android.

</comment></comment></comment></comment><comment><USER9> I was thinking about this the other day - with netbooks, tablets and smartphones running Android showing no signs of slowing down; Android really does seem to be "the dream come true" in terms of "Is this the year of the Linux desktop" kind of dream.

It's kind of exciting and also kind of scary. I'm not a fan of the Android development stack at all, and this comes from someone who's been championing Android over iOS for the past several years. I think overwhelmingly it's probably a good thing, I just won't be dabbling too much.

<comment><USER10> If you don't like the stack, why do you think it is a good thing that it should become so widespread?

</comment></comment><comment><USER11> Two comments here converge on a complete response to Chris DiBona's assertion:

"A platform controlled by a single vendor and locked down by hardware vendors != the Linux desktop "dream come true"

"For smartphones, sure. For desktops this is not going to happen for a long time if ever."

As much as Android is now both the dominant client Java and the dominant Linux userland, there are two things that have to happen before it is the Linux "dream come true."

First, it should become really open, without a Google controlled two-tier structure for OEMs. Not all open source, but open to all comers: Anyone who makes an Android device that passes compatibly tests should be able to ship the Android Market on it. In this, Microsoft is more even-handed with OEMs. Any OEM can license Windows, and they get the same thing HP and Dell get.

Second, Google needs to make this openness and evenhandedness happen for tablet makers, which are more like desktop PC makers than handset makers. Tablets are not tied to mobile networks, nor to mobile network operators' retail channels. There is no mobile operator dictating what the software content of a tablet must be in order for it to be accepted by their channel, so there is no excuse for the process to be less than transparent and open to every product that passes compatibility tests.

<comment><USER12> If you sign a deal with Google, you also get the same treatment as other companies that signed a deal with Google.

The difference between Microsoft and Google is that if you don't license Windows, Microsoft gives you nothing. Big, fat 0. If you don't sign a deal with Google, you get 95% of Android.

Your demands perfectly illustrate human nature: no matter how good you have, not matter how much you have, there's always more to want and demand.

With Android Google is being generous to extreme, unprecedented levels. They give away, for free, with source code, technology that would require millions to redevelop from scratch, but that's not good enough for you. And the same time, you make no demands on Apple or Microsoft to be even 1% as generous as Google is.

The restrictions that Google has on Android have very good rationale: to prevent explosion of incompatibilities, something that has plagued uncoordinated desktop Linux efforts for years and has no signs of being resolved. rpm vs. apt vs. yam. Gnome vs. Qt. etc.

And finally, no matter how many of your demands Google will meet, people will always come up with more. You have already demonstrated that you'll find a fault with a very big and generous gift of Android. I can easily imagine that after Google lifts the restrictions that bother you so much (even though the likelihood that you're personally affected by them is 0) someone will consider that 30% royalty in Android Market is too high.

<comment><USER13> >If you sign a deal with Google, you also get the same treatment as other companies that signed a deal with Google.

Do you have any evidence to support this statement? Agreements of that nature are not normally made public, and the circumstances surrounding the google maps/GPS on android thing, means this is very likely not the case.

>The restrictions that Google has on Android have very good rationale.

Im so happy that google is choosing to restrict my freedom to use my devices for my own good, thank you google.

>You have already demonstrated that you'll find a fault with a very big and generous gift of Android. I can easily imagine that after Google lifts the restrictions that bother you so much (even though the likelihood that you're personally affected by them is 0)

Android is not a gift, its intent was never to charitably donate something to the community at large, its intent was to make google money. Their entire platform is based off of the open-source work of others, it did not spring forth from google fully formed, expecting reciprocation is not too much to ask.

<comment><USER14> > Im so happy that google is choosing to restrict my freedom to use my devices

Google is not 'restricting your freedom'. You can fork android and do whatever you want.

> Android is not a gift, its intent was never to charitably donate something > to the community at large, its intent was to make google money

Intent is irrelevant. Pre Google: 0 commercially viable Linux based phones. Post Google: dozens.

> Their entire platform is based off of the open-source work of others, it did > not spring forth from google fully formed, expecting reciprocation is not > too much to ask.

They do reciprocate. The source for android is yours to hack.

<comment><USER13> >Google is not 'restricting your freedom'. You can fork android and do whatever you want.

that is a bit of a hobson's choice, sure (some of) the code is available (pre 3.0), but without a device that is open and able to run it, it may as well be closed.

>Intent is irrelevant.

Intent is everything, would you be right to suspect the motivations of a mining company conducting a review of environmental impacts, even if the results appear sound on the surface?

>They do reciprocate. The source for android is yours to hack.

Except for of course, gingerbread.

<comment><USER8> _that is a bit of a hobson's choice, sure (some of) the code is available (pre 3.0), but without a device that is open and able to run it, it may as well be closed._

I'm not sure what you define as "a device that is open", but surely the many unlocked handsets apply?

If not, then <http://beagleboard.org/project/android/> perhaps?

If not, then maybe the Nokia 810: [http://www.linuxfordevices.com/c/a/Linux- For-Devices-Article...](http://www.linuxfordevices.com/c/a/Linux-For-Devices- Articles/Porting-Android-to-a-new-device/)

Am I missing your point somehow?

</comment></comment></comment></comment></comment></comment><comment><USER15> there are dreams and there are nightmares.

</comment><comment><USER16> Previous discussion from earlier today: <http://news.ycombinator.com/item?id=2755050>

</comment><comment><USER17> I do not see X dying for the foreseable future, but if there was good android support on X, many android apps are better than the accessories included in gnome/kde/xfce. I don't understand how Android is a "linux desktop" at the moment.

On the other hand, Android will be the closest thing to "linux everywhere (but the desktop)" . It could power TV sets, washing machines, car navigators, watches etc. Looking forward to using it on my next Roomba.

</comment><comment><USER18> For smartphones, sure. For desktops this is not going to happen for a long time if ever. When will AutoCAD, UGS-NX, MAYA, Photoshop, Quark Express, MatLAB, Mathematica (other than wolfram alpha), and even more specialized medical/industrial/scientific software be available for android? Will there even be decent gaming under java? (angry birds does not count)

<comment><USER19> > Will there even be decent gaming under java? (angry birds does not count)

Minecraft is written in Java.

> When will ... even more specialized medical/industrial/scientific software > be available for android?

Presumably when the people buying the software begin to express an interest in moving to android. I'm not saying that it will happen, just that the software will be ported over, or new software written, when people start wanting it.

I don't think that anyone seriously believes that android is going to replace OS X and Windows on desktops, just that, as time goes on, people will be spending more and more time on tablets and smartphones and less on traditional desktops and laptops. I find it a bit sad, mostly because I refuse to believe that I'll ever be able to type as quickly on a tablet as I do on a keyboard.

</comment></comment><comment><USER4> Haha. Yes, yes it is.</comment>


Invoke Win32 applications with Bash on Windows - <AUTHOR> https://msdn.microsoft.com/en-us/commandline/wsl/interop <comment><USER2> This finally makes bash on windows functional. It was one of its limitations that made it feel disconnected from the rest of Windows.

<comment><USER3> It also introduces potentially significant new attack surface.

<comment><USER4> Any more so than, say, using bash and friends via cygwin or similar?

<comment><USER5> Maybe. Cygwin is old code and sometimes that's better than new code from a security point of view.

</comment></comment></comment></comment><comment><USER6> Wow, this is really impressive. Last time I worked with bash on Windows it felt like isolated island. But with this. I think it is a viable option right now. The only down side to it is slow file system operations. Compiling a single toy kernel (xv6) would take much longer than Linux.

This is amazing, now I can have emacs server in Linux running through bash with windows service manager.

This is fucking awesome. I hope they improve thing further and further.

The only and biggest problem : Windows ridiculous conemu. I am not going use a console which I can't resize without any problem. For the sake of God they don't have unlimited buffer option and hide scrollbar (permanently) or resize window without messing up text.

<comment><USER7> > "Windows ridiculous conemu. I am not going use a console which I can't > resize without any problem."

Sorry I don't follow. What resizing problems are you having with ConEmu? Works fine when I've tried it. We are talking about the same ConEmu, right?

[http://conemu.github.io/en/](http://conemu.github.io/en/)

[http://conemu.github.io/en/ResizeAndMove.html](http://conemu.github.io/en/ResizeAndMove.html)

<comment><USER8> The way they phrased it suggests they were referring to the default Windows NT terminal emulator, rather than Conemu.

<comment><USER7> I would agree with you, but that'd be the first time I've ever heard that called ConEmu. It's much more likely to be called the Windows command shell, Windows command prompt or cmd. As you're clearly already aware, ConEmu is a specific product that provides an enhanced command line experience on Windows.

<comment><USER9> FWIW, `cmd.exe` is both, the shell and the console. It is not a terminal (not designed to be operated remotely) nor is it emulating a terminal of any kind.

As for the parent poster, they must be abusing the term `ConEmu`, a completely separate console program that can run win32 programs (including `cmd.exe`).

<comment><USER10> If it helps futher square some of the linguistics digressions the parts of cmd.exe that are the console emulator are typically referred to as the ConHost. The ConHost's console emulation is indeed not quite as great a lot of people would like, which is why many Windows users use a different console emulator named ConEmu. Obviously abbreviating the ability of ConHost's console emulation to conemu rather than spell out "console emulation" causes confusion with the ConEmu tool for Windows.

</comment></comment></comment></comment></comment></comment><comment><USER11> There's a lot more technical information in this post (scroll below the video for diagrams and writeup): [https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows- and-...](https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu- interoperability/)

</comment><comment><USER12> Now they just need a better terminal emulator. Windows 10 made some minor but much needed adjustment, but I still end up using Cmdr (a nicely preconfigured ConEmu), and it's decent enough, but it pales over a nicely configured iTerm2 or what most popular Linux distros come with out of the box.

<comment><USER13> I second this. Someone porting iTerm2 to Windows would make my day.

</comment></comment><comment><USER14> We're not on Windows 10 yet at my workplace, and I don't use Windows at home, so I've only been following loosely in a "this will be nice once I'm finally able to use it" way. But this bit took me by surprise:

> 1 Use the same working directory as the CMD or PowerShell prompt > 2 Are run > under as the WSL default user > 3 Have the same Windows administrative > rights as the calling process and terminal

1 and 3 are not surprising. But 2? There's a WSL default user? Windows users aren't automatically mapped to unique Linux users? That seems problematic in theory. How does it work out in practice?

<comment><USER10> It seems to work pretty well in practice. The entire Ubuntu "system" is essentially installed into a Windows User's home space, which means that all of the Linux users are unique to a Windows user. This is useful in that you can install things that need Linux accounts for services (like say postgresql that uses a postgres user as a service account) and interact with it with sudo -u just as you would on an ordinary Ubuntu machine. With the interesting bit that the postgres user under my Windows user login would be different from the one under a different Windows user on the same machine, but that also has some advantages.

<comment><USER14> Thanks. That is a helpful explanation.

</comment></comment></comment><comment><USER15> If there's ever been a great opportunity to open source something in the Windows client, it's WSL. A number of popular User Voice feature requests were closed recently as not in scope, which is reasonable on the part of the WSL team but shows that the demand for Linux-on-Windows is much greater than the team's current objectives. If the project was open source and the team accepted patches who knows where this thing could go. People want to run X, they want device emulation, they want to run all kinds of apps that aren't necessarily dev tools.

</comment><comment><USER16> Oh, that's nice. That's what I was looking for in the first place.

As I'm reading the comments I keep seeing things that other people want to do that I never thought of...that's awesome.

</comment><comment><USER17> I'm guessing this solves:

[https://news.ycombinator.com/item?id=12715945](https://news.ycombinator.com/item?id=12715945)

</comment><comment><USER18> Embrace, extend and invoke? ;)</comment>


45 tax-free commercial zones in UAE - <AUTHOR> http://gulfnews.com/guides/life/property/45-free-zones-in-the-uae-find-the-right-one-for-your-new-business-1.1716197 <comment><AUTHOR> I was surprised by how far the exemptions go. The Biotech Research Park in Dubai include tax free salaries for all employees.</comment>