What Are the Tricky Parts of Embedded Development? - <AUTHOR> http://embedded.fm/blog/2017/2/17/what-are-the-tricky-parts-of-embedded-development <comment><USER3> Those are all beginner embedded problems. Big problems include

* You're developing a controller that controls something. Now you have to have the hardware it controls. This can be a sizable piece of industrial equipment. You may need a simulator for it.

* I've seen auto engine controls developed. Phase I was run connected to an engine simulator. Phase 2 was run connected to a test board with the auto components, including one spark plug, and an analog computer to simulate the vehicle power train. Phase 3 was run on a test stand with a real engine. Phase 4 was run in a car with a debug system plugged in. Yes, you need all that stuff.

* Safety issues. You may need a separate safety system to monitor the primary system and shut it down. Traffic lights have a simple hard-wired device which has inputs from all the green lamps, and a PC board wired with diodes to indicate which can't be on at the same time. If the checker detects a conflict, a relay trips, all the lights go to flashing red, and the CPU can't do anything about it. Some systems allow the CPU to try again after 30 seconds of flashing red, but usually it requires someone to come out and replace the electronics.

* JTAG is your friend, but JTAG is so low-level that it's a huge pain.

<comment><USER4> Phase 1 was running with blinky leds on breadboard. Phase 2 was prototyped version running under the seat of my motorcycle hooked up ti the engine sensors and datalogging the output of my hardware/software compared to the OEM ignition/FI while I rode it round the block and local neighbourhood a few times. Phase 3 was hooking my version up and riding it around... Safety issues, huh? ;-)

(Arduino driven ignition and fuel injection for a motorcycle a bunch of years back. Gave up on it 'cause though it worked well, I never got it reliable enough. Fun way to waste a year or so's worth of weekends/evenings...))

<comment><USER5> Look into megasquirt. I did a completely custom setup with it years ago and it was great. Put a few thousands miles on the car, as reliable as OEM. Built the thing from a blank citruit board, built my own wideband controller too. Was damn surprised that everything worked.

Support was pretty good for custom sensors, only problem is your knowledge has to run damn deep with these things before you can get the engine to start :)

I had wideband autotune for O2, idle control, knock retard, coolant and air temp compensation, basically every original sensor from the motor and a few extras I bolted on worked great

Of course, you need to know how to get an engine running from a blank fuel and spark map...And blank enrichment/retard and aux maps for all these sensors.

Anyways, was good fun. Lot more interesting than the toy stuff people are doing with Arduinos for the most part

<comment><USER6> I've heard better things about DIYEFI, mostly entirely because megasquirt isn't properly open source. Other than that I think they're both pretty good.

[http://www.diyefi.org/why.htm](http://www.diyefi.org/why.htm)

</comment></comment></comment></comment><comment><USER7> For me it was working with vendors. Coming from web dev, that was the biggest change, that you can't just open an account with Heroku/AWS/whatever and go about your business like you would if you were hacking for yourself.

You've first got to figure out what kind of SOC you want, and no it's likely not Arduino/RPi or whatever is popular for hacking projects. And no it's not the EE responsibility to choose these things; they just route them. _You_ have to work with vendors to figure out what performance characteristics, lifespan, etc you'll need for your system along with preferences such as OS support (first class, 2nd class, community/experimental, etc, because no, you don't typically just download and install the latest Ubuntu and call it a day; drivers etc are often custom and proprietary, so unless you want to write your own driver stack...). It all doesn't "just work out of the box" like a SAAS service. You've got to put a lot of thought into "other stuff" and make some big decisions before you even write a line of code.

<comment><USER8> I'm one of those EEs, and I think you're short-selling your colleagues. Or maybe your organization hasn't found great hardware people. Where I've worked, the hardware folks are (on average) just as responsible for architecture as the embedded software folks.

Anything less than equal-and-honest cooperation tends to lead to lopsided or quirky designs.

<comment><USER9> I'll chime in with a confirmation that, in my experience, too, an EE who "just routes them" is either not very good, or working in a dysfunctional organization. Performance isn't something that exists in its own bubble, it comes with clock and power requirements and the devices that offer "more" of it than other devices have to compromise on other things. If a company insists on enforcing a strict hardware/software team separation, both teams have to be involved in these decisions, otherwise the results are borderline catastrophic -- boards that can barely be programmed and debugged, or sub-optimal component choice, bad analog chains, difficult clock distribution etc., depending on who is more involved in the decisions.

Just like, past a certain point, it's impossible to do good embedded development on the software side without at least some basic knowledge of EE, there's no way you can come up with a good hardware design if you're completely ignorant about software development. It's no coincidence that the best engineers are the ones who can do both.

<comment><USER7> Sure, you're both correct. I totally understated the EE's role. My intended point was that you can't expect the EE to just "design the board and give it to you". Coming from web / PC app dev this was a big shock. It's a team effort to figure out what hardware is necessary and form relationships with vendors, and the SWE's are by no means absolved from that process. After a few years of embedded dev now, it now seems odd that I'd have been surprised by that, but nonetheless I was.

<comment><USER9> Oops :-). Sorry if I seemed overly pedantic. I was bit by the EEs who literally "just route them" a long time ago and I'm not very sympathetic towards them. I'm one of the weirdoes who are programmers by profession but have an EE degree (not that I'm a good electrical engineer -- I just know enough to troubleshoot my way around hardware bringups and talk to the _real_ EEs), so I find the whole "just tell me what connections you need" attitude particularly infuriating and conducive to terrible designs.

</comment></comment></comment></comment></comment><comment><USER10> The tricky parts of embedded development? Take all the tricky parts of making all the functional elements of a computer, kill the supportive community, demolish a couple bells and whistles, burn all pertinent documentation, and, most importantly, give it to a single developer to handle all by their lonesome.

<comment><USER11> Your comment perfectly encapsulates my experience doing embedded development for a military contractor.

<comment><USER12> It can also be a fun/technically challenging niche job that avoids the paperwork endemic to many jobs in large contractors.

</comment></comment></comment><comment><USER13> I'm a huge fan of simulations, I don't think you can develop a 'good' embedded system without it. My way of implementing something embedded is:

* Develop a capture program for the input feed/sensors, and capture as much as you can.

* Develop a software model to recreate the input for a 'target' embedded system

* Write the embedded system against the captured input. That will get you 95% there.

* Run it 'live', check anything wrong (you will). Usual debugging & tweaks.

* Do a feedback loop if problem input comes in, and keep /that/ preciously for your test unit sequence.

* Once software is done, every time you make a change, run your simulator with all the test input you have and check your output for divergence.

I very, VERY rarely need to JTAG into a board, I'd rather spend the time on the simulation model and get it accurate as I can than spend time 'debugging' on the target.

That's why I wrote simavr for example [0], but I also use qemu _lot_ for bigger systems. Unfortunately it's next to impossible to get anything upstream in qemu, so most of the work there just is dropped eventually [1].

[0]: [https://github.com/buserror/simavr](https://github.com/buserror/simavr)

[1]: [https://github.com/buserror/qemu- buserror](https://github.com/buserror/qemu-buserror)

<comment><USER14> Do you have any suggestions on deciding where to draw the line for simulation? It seems that you are suggesting instruction-level simulation of the same binary which is going to be deployed, correct?

What is the performance you're usually seeing for simulations like that?

<comment><USER13> No I do not necessarily advocate instruction level -- sometime it's just not practical. If course if you _can_ it's good (aka QEMU or simavr) but sometime it's not possible or not necessary.

For example in my last opens source project. I fed the signal I was receiving to a plain linux program, because I was more interested in the algorithm than the pure embedded bit. THEN I transposed it all into the embedded firmware as is (See [0], there are still remnant of that in the rather shotgun-style linux program).

So 'applicative' simulation is as good for many cases, while the instruction level is good when you want to validate the /true/ embedded responses of the real CPU...

The idea is primarily to be able to isolate the problems, and be able to develop/test them in a feedback loop _individually_ if possible.

As for instruction level speed, well, these days QEMU is likely to be at least as fast as a good ARM CPU without any problem (very often, a lot quicker). And simavr is several hundred times quicker than a real AVR when running on a x86* host. In fact, it's often more of a problem trying to simulate 'real time' like input/timers than the other way around...

[0]: [https://github.com/buserror/rf_bridge](https://github.com/buserror/rf_bridge)

<comment><USER15> You are wise.

This is how I develop, too.

The strategy is essentially to develop the algorithm/software outside the embedded platform, then port it to the embedded platform. I, too, record input data streams and process them via desktop. Then I stream the recorded data through the embedded system.

In the worst case, updates can be made in the embedded system, but in the best case, they can be developed and proven outside then the benefits carried out into the embedded system.

These days, I firewall as much code as possible into "flat", "pure" C/C++ files that contain no low-level calls or libraries or includes whatsoever. Even my tasks under RTX are wrappers to the actual tasks. I can run my multi- task programs under linux just fine with a pseudo task manager. My build system uses _the same exact C files_ for both the desktop and embedded code. There are layers of API calls, but the compiler just optimizes them all out so I don't even sweat it.

You might think that makes it less "realistic," but in practice, it makes it more robust, since the tasks are (mostly!) coded to run at any frequency or pattern of switching.

You might think this massive front-loading takes time, but it's never wasted. Things come out so clean at the end. Especially because lots of documentation can be written between the desktop and the embedded porting.

I was inspired to do this by projects like MAME and MIDIBox. Both are multi- media real-time system across numerous platforms. They benefit from repeated porting. It shakes the bugs out.

</comment></comment></comment></comment><comment><USER16> Bad documentation. The worst documentation is the documentation that _looks_ professional and complete . . . and lies through its teeth. And the support staff at $VENDOR is just reading the same documentation that you are trying to decode, and it takes weeks to get a round-trip through their ticket system.

Once I submitted an issue with a workaround that had some rather nasty side- effects, and asked for a better solution. Weeks went by. They were promising a code sample. More weeks, more "Well, we're still working on this." The solution I got back, about a month later, was exactly the workaround I'd included in the support request, with some of the serial numbers filed off.

One issue took months to resolve. We finally told $VENDOR "Look, we've got to ship. But we can't if we can't get this (critical component) working, and we'll be forced to ditch you." That got all kinds of political bullshit out of the way, and in an hour we were talking to the guy who had designed the circuit we were having trouble with.

"Oh," he said, "You have to do (three simple steps)". And I tried it while one of my cow-orkers kept him on the phone, and it worked.

I never want to deal with $VENDOR again.

<comment><USER17> Yes, I totally agree with this. I spent weeks debugging some some unexpected behavior with a flash memory chip, only to learn that some crucial information was "explained" in one very cryptic sentence. It turns out the datasheet was originally written in Korean and the translated, poorly, into English.

<comment><USER18> My favorite translation blip came from an Advantest calibration manual:

"Adjust [setting] until the sun shines most brightly upon the screen."

Fortunately, the setting did not have any effect on our friendly neighborhood ball of fusing hydrogen, and a bit of fiddling around eventually revealed that the instrument had turned its gain way up, allowing one to easily determine the zero point by adjusting the bias until the screen filled with noise (rather than pegging at the top or bottom). If one were to squint a bit, I suppose it might look like the sun shining on the screen?

</comment></comment></comment><comment><USER19> for me, its that the hardware doesn't always work or at least not as you expect. if you write workstation or server code, 99.99999% of your problems will be software bugs. But on an embedded system, especially something custom, you can have weird, intermittent hardware behavior that takes a lot of work to pin down. and sometimes you can't fix it so you workaround. It's both rewarding to get this stuff to work while at the same time extremely frustrating.

I've worked embedded systems for years but every year I tell my colleagues that I'm switching to IT so if my hardware doesn't work I can just throw it away and buy a new workstation.

<comment><USER20> "Fun" problems from my embedded systems career in no particular order:

1)Writing device drivers for a chip that I can't get to work. Has to be my code, this is a basic function of the chip; why am I so stupid??!!? Finally call the vendor: oh, yeah we know about that bug, the next revision fixes it. Why isn't everyone else screaming about this problem? Well, you guys are only the second company to sample this chip. The first one found the bug!

2) System has to autoload a tray when operator closes the door. Works fine right up until it doesn't. Turns out some of the (visually opaque) trays are transparent at the infrared wavelength of the sensor that detects them.

3) (on a call with Field Service). Intermittent problem that seems to be software: a moving carriage is reporting errors, but only during certain moves. Field tech has replaced every relevant module and problem still happens. On a hunch I have him disable the safety interlocks and open all the doors to watch what happens. Problem is that there is a weak spot in an cable in an unrelated assembly that causes it to momentarily collide with the carriage, making the carriage fail to get to its destination. By the time they both stop moving, all hardware tests fine, so no one suspected the other assembly.

4) I love telling this one: hardware caught on fire because a jammed assembly caused a motor driver to overheat. Tester filed a bug against the software because it didn't report an error to the user. _The CPU was fkn toasted!_

<comment><USER21> More stories, please.

</comment></comment></comment><comment><USER22> My answer (not mentioned in article): cycle time. So many code-bases with no tests and no useful emulator.

So each "cycle" can be as long as, flash the thing, wait for it to warm up, get the device into the right state, test the thing you wanted to test (which might involve another device etc).

<comment><USER23> Any chance one could virtualise some or most parts of the hardware?

<comment><USER24> If you're developing the firmware, use a Hardware Abstraction Layer (HAL), and having the application logic only communicate with/through that. Have a version of this layer which can run on your host computer. The majority of the code then becomes testable with very quick cycles.

The HAL layer for device must be tested separately. Ideally do it in an automated systems test jig, which has the target hardware+software, and allow programmable input stimuli and output verification. You really should have such a setup for your final (per-board) QA anyway, so better to start developing it sooner rather than later.

<comment><USER25> This is money and time. Great if you have it.

<comment><USER24> Yes like everything else. HAL and host-based simulation usually lets you start developing the software earlier in the product cycle, which can make available a lot of time. If one doesn't have the capacity to invest in automated QA then things might get tricky no matter how things are done... Trying to simplify the problem / reducing scope might be best course of action.

</comment></comment></comment></comment></comment><comment><USER11> As a former embedded developer, there is another aspect of difficulty that hasn't been touched on. Dealing constantly with physical hardware introduces a host of challenges.

* If you or your coworkers are not organized, you can waste a lot of time looking for proper sized wrenches, proprietary screw heads, speciality crimpers, oscilloscope probes, etc. etc. The more hardware the company makes, the worse this problem can be.

* Most internal connectors are not meant to be constantly plugged and unplugged. In a testing scenario where you have to change connectors or test harnesses frequently, it is common for the connectors to break or wires to become loose. Then you have to waste time figuring out why your hardware stopped working.

</comment><comment><USER26> Another big challenge is that most of the embedded software I have seen is written by people who aren't exactly top notch programmers.

I spent a about 15 years mostly writing server code for UNIX machines in C (before ditching it in favor of Java, and 13 years later: Go). Since embedded programming is a bit of a specialty field where things like predictable performance and robustness is important, I expected the embedded world to be pretty professional. Because any time people start using words like "guarantees" or "real-time", you tend to assume that they do some pretty amazing stuff.

I can't really say that's what I found. A lot of code is brutally ugly, many lack understanding of even the most basic defensive programming techniques and there's a lot of superstition around abstractions by people who don't really seem to understand what comes out of a compiler (Having the compiler "compile away" abstraction layers was something we often obsessed over on projects I worked on in the 90s and early 00s).

Code is often badly organized, badly formatted, badly documented and amateurishly maintained (eg bullshit commit logs -- if the source is even kept in a version control system). As a result, you constantly fight the urge to rewrite stuff because the code is just so damn hairy. Of course, any talk of rewriting code makes people nervous ("we invested a lot in order for this to work and now it does! Don't touch it". Yeah, I'm not surprised it took a lot of work)

And all of this was code by serious companies whose brands you have heard of.

I'm hoping the IoT craze is going to accomplish at least one thing: educate embedded developers. Sure, a lot of us "regular" software people are going to run around like a bunch of flatfooted morons because it is unfamiliar territory, but the embedded world is in _dire_ need of some software culture and discipline.

<comment><USER27> I think a lot of that is changing due to the rise of Linux in embedded systems. Many more traditional software engineering concepts are becoming mainstream in embedded.

And for embedded in high value (hundreds of millions of dollars) or human life, I think there has always been lots of proper discipline and engineering process.

<comment><USER26> I was mostly talking about stuff that runs on much smaller CPUs that have from a few hundred bytes to a few tens of kilobytes of memory. Those kinds of devices are important for applications where you have extremely tight power constraints (like powering stuff off a coin-cell battery for two years etc).

</comment></comment></comment><comment><USER28> * You're going back in time about 10-20 years in terms of tool chains, language support, memory/CPU power, debuggers, and for the most part programming paradigms.

* Documentation? HAHAHAHAHAHAHAHA LOL

* Debugging can be extremely challenging in real-time systems. Things like JTAG printf will slow things down enough to wreck your timings.

* You have to at least know the basics about the hardware, especially if you're doing control systems and meddling with GPIOs and such.

</comment><comment><USER29> Ugh. Dealing some of this right now. 3 full minutes to compile and flash 430kbs to a board. And then the debug tools won't use break points properly. 400kbs are system libraries I can't avoid. I'm thinking of writing a lisp compiler with some ffi and pushing it to the remote memory via tcp. Even having to write my own debugging tools I feel like I might save time.

<comment><USER30> Oh, you have a debugger you lucky sod.

Currently working on a thing (approaching EOL thankfully, but still have to support and add new features until the manufacturer says "no seriously we're cutting you off") that uses a gcc cross compiler from the 90s, no gdb for me.

Side channel debugging is a life skill. Oh it's crashing weirdly with no diagnostic output on the UART terminal? Rewrite a timer interrupt that's still running to print your diagnostic information when you toggle a switch. It's actually fun if there's not deadline pressure or a line down situation at a customer.

</comment></comment><comment><USER31> A tiny favorite I remember from when I started working for real as an embedded developer ~5 years ago (before that I was in AAA game development, quite the switch in so many ways!):

I was taking over development of a new display driver for a small hand-held instrument. The display and drivers were both new to the organization, so there was no experience in-house. And we had these strange "color-flowing" bugs, that nobody could understand. Fields of greens and blues that bled across the screen in weird ways. Of course everybody thought it was a driver (=software) bug.

Weeks passed, my hair got thinner, then finally I looked once more on the schematics, traced a signal back to the CPU, and said to the hardware designer "hey, isn't this a 3.3-volt signal?" Turned out we were _backfeeding_ the display driver from its reset line, causing it to power up due to the voltage overpowering the input circuitry and flowing into the power rail, enough to power it up but not to make it behave correctly. Yikes that was frustrating (but fun to catch, of course).

<comment><USER27> Good story.

I've come to realize software almost always gets the initial blame. Software is almost always the one painting the error screen. So even if it says "Voltage out of range", someone is going to accuse software of not working. So they pull you into the lab, watch you open the box, probe it with a multimeter, show that the voltage is out of range, and then get the hardware engineer.

I once spent over a month (nights & weekends) tracking down a memory corruption bug. Everyone accused software of course. It turned out to be poor signal integrity on the memory bus (hardware problem). It was horrible.

</comment></comment><comment><USER32> Real hardware regularly fails and you need to recover or people will think your device is flakey. Consider running a program for 20 years on a single chip without someone rebooting ever. Now, consider 100,000 people doing this and everyone thinking something is broken if it fails.

<comment><USER20> This is always the "fun" part. You're writing code for a medical device that is processing somebody's blood and there may be a physician waiting for the test results. 40 minutes into the test a pump jams or gets sticky from all the fluid it has to push around all day. You absolutely do not want to throw that blood sample away and start over. Hell, there may be no sample left and a nurse is going to have to go stick the baby again to get more. Now you have to figure out a sequence that can recover the hardware to keep processing that test, while not affecting the other 100 tests that are also running in parallel with it. And then design this for all the potential failure points in the system...

Yea, "fun"

</comment></comment><comment><USER33> My experience: working with the hardware engineers and convincing them of things like yes, you need to latch those signals because, no, I can't poll the signals often enough to avoid missing events.

<comment><USER34> "We didn't put in hardware PWM because we figured you could bitbang it in software."

<comment><USER33> Right?

</comment></comment></comment><comment><USER35> One of the tricky part is documentation. The PDF for an STM32 (something way smaller than a beaglebone or a raspberry) is 1700 pages long, it includes the 69 pages long description of a timer, but doesn't include any ARM core documentation.

RTFM is a nightmare, the time you look at another page for a related device, you have forgotten what you read previously.

<comment><USER36> The STM32s have an odd documentation structure where you have a datasheet (showing pinouts and capabilities of a specific part or subfamily), a reference manual (showing the detailed structure and function of all peripherals, common to the part family) and a programming manual (documenting the core, common to all parts using that core). So in this case, you're looking at the wrong document.

<comment><USER37> I think a lot of the larger devices do this, otherwise there would be a lot of repetition across the family.

</comment></comment></comment><comment><USER38> I wasn't really an embedded developer ever but I worked at an industrial IoT company for awhile and used to just get handed devices which I was supposed to connect to the internet and figure out how to make them send useful data to us.

Besides the undocumented proprietary protocols which isn't embedded specific as a backend engineer I used to struggle heavily with development environment setup. As a JVM and Python guy I'm not used to fucking with weird compiler tool chains at all.

</comment><comment><USER39> I found that doing endian conversion for a system using both PCI and VME buses was quite a challenge.

I also found it a challenge writing Linux device drivers for chips with an external 32 bit bus and an internal 16 bit one. The 32 bit data had to be split into two, set the data pins for the first half, set a bit saying the data was available, wait for it to be read in and repeat with the second half. Do the reverse for reading.

Also challenging was setting the bits in a register for a chip with multiple commands per register. My program checked the input data for an error, e.g. trying to set three bits to 128, read the register, masked out the bits to be changed, changed them, wrote the value, read the register, masked out the bits and checked them to make sure they had been changed.

Then there was the time the board manufacturer changed the memory map of the board without telling us. Boards made before April would boot, newer ones didn't.

I also found that some device drivers from SOC chip manufacturers had to be debugged before I could use them.

<comment><USER40> Don't you mean "Internal 32 bit bus/external 16 bit"?

</comment></comment><comment><USER24> Isn't the "Mbed compiler" just GCC running on their servers?

I've successfully made code that worked just fine with the online MBed IDE and gcc-none-arm-eabi, I don't recall anything having to be done differently, just more to setup locally (linker scripts and so on).

<comment> fake-name I think they've added a fair bit of stuff to it, and are unwilling to release their source, because they don't _actually_ ship the modified GCC, they can not release their changes.

IIRC, most of the stuff they've added are surrounding libraries and such.

It's basically a canonical example of why the Affero GPL exists.

<comment><USER41> The big benefit of using mbed is there really nice API which abstracts the hardware. The code for the API is Apache, and available on github[1].

Furthermore, you don't even need to use their online IDE to do anything. The online IDE has an option to export your project such that it can be built with arm-none-abi-gcc and make[2], or you can use their mbed-cli tool, which is a python based command line tool, and is also on github[3].

The mbed guys have way embraced open source and working with existing tools, and I wished the community would embrace them more, since I think their API's beat the snot out of Arduino.

[1]: [https://github.com/ARMmbed/mbed-os](https://github.com/ARMmbed/mbed-os) [2]: [https://developer.mbed.org/handbook/Exporting-to-offline- too...](https://developer.mbed.org/handbook/Exporting-to-offline-toolchains) [3]: [https://github.com/ARMmbed/mbed-cli](https://github.com/ARMmbed/mbed- cli)

<comment> fake-name Huh, I guess that's changed. I remember looking at mbed at one point, and at that time it had no offline option (which basically made it a non-option for me).

I'll have to re-evaluate it the next time I need a little mcu board!

</comment></comment></comment></comment><comment><USER42> Here is this moderately complex embedded system.

Simple challenge: the system must run 24/7, without interruption, for at least a year. Bug free.

Quite the tricky thing to achieve.

</comment><comment><USER43> Is embedded work, in general, well paid? And is it relatively easy to get new work once you've broken into it?

It seems to be not very visible. I'm under the impression that some "not very visible" work is well paid and not going away any time soon. I'm thinking of some cobol or pascal developer called out of retirement at great expense.

Or is this like being at the edge of new/exotic web 2.0 where you are continually looking for the next job, re-learning tech over and over.

I know this is a big topic and perhaps there is no correct answer overall.

If anyone has any resources to job sites or further articles I'd love to read them.

<comment><USER25> > Is embedded work, in general, well paid?

The trick is breadth of knowledge. If you can just program a microcontroller, you've got a lot of competition. If you can program a microcontroller _AND_ an FPGA, your competition dropped by orders of magnitude (this is the biggest step and probably the easiest to tack on--Verilog isn't that hard but you _WILL_ foul up until you get race conditions and concurrency properly beaten into your head--do everything synchronously and synchronizers are your friends). If you can program a microcontroller, program an FPGA, _AND_ design the board--you are in rare company. If you are good at _debugging_ these boards, people will worship you as a god. If you have domain knowledge on top of that, you should be starting a company.

> And is it relatively easy to get new work once you've broken into it?

Well, it's networking like anything else. If you've been doing it for 10 years, things seem to just drop into your lap. Otherwise, you have to beat the bushes.

However, if you do a good job, the good people around will notice quickly. And those good people are often at capacity so they will throw stuff over to you.

Obviously, being near a tech hub helps.

> I'm under the impression that some "not very visible" work is well paid and > not going away any time soon.

The problem with "not very visible" is that it also means "executive level may not appreciate it". I've seen medical device companies trying very hard to get rid of the single person who actually understands their hardware.

> Or is this like being at the edge of new/exotic web 2.0 where you are > continually looking for the next job, re-learning tech over and over.

No and yes. :)

ARM is dominating the embedded space currently. So, especially at the Cortex M end of the spectrum, the base programming environment looks pretty much the same. This hasn't changed for quite a lot of years.

In addition, 8-bit development is mostly going away. The delta between an 8-bit micro and a 32-bit micro is now so small that it makes no sense to use anything other than 32-bits unless you have a _very_ specific use case.

For FPGA, the tools are similarly stable over long time frames.

The peripherals, on the other hand, completely differ from manufacturer to manufacturer. And have bugs from revision to revision. So, that is like learning stuff over and over :(

However, what the peripheral are supposed to _DO_ is stable. Once you understand that, you will be very good at ferreting out the small differences and your life gets some easier.

> If anyone has any resources to job sites or further articles I'd love to > read them.

You can read a lot, but doing is better. Go get a Nordic BLE development kit for $39 and build something.

[http://www.digikey.com/product-detail/en/nordic- semiconducto...](http://www.digikey.com/product-detail/en/nordic- semiconductor-asa/NRF52-DK/1490-1053-ND/5773879)

<comment><USER43> Thanks, this is by far the most comprehensive reply I've ever had on HN. I appreciate you taking the time, I'll look into your suggestions. I actually have an atmega 8515 but I've been a little distracted learning the finer (if that's the right word) points of c++ recently. Do you think the 8515 is "appropriate" ?

<comment><USER44> I'm not the original poster, but starting with bare MCU might be too tricky at first. A better approach imho would be to get some of many available kits (i.e. Beaglebone) and try to make it live from scratch: don't use prepared bootloader/OS, but try to build everything yourself. Setting up a toolchain, grasping cross-compiling, downloading and debugging "doesn't start" kind of problems are the key and every day problems in embedded programing. When you are familiar with the build-download-debug process, get into peripherals: GPIO, UART, SPI, memory interfaces etc. After this, you should have enough experience and spent enough time on reading obscure datasheets to start designing your first, simple boards. Sure, you also need some electronics knowledge to read, understand and layout schematics, but provided you don't get into RF or analog electronics, it's not too difficult.

<comment><USER25> I'm going to disagree here about the Beaglebone (or RPi) first. There is a _LOT_ of complexity in those that simply isn't in the Cortex-M (especially M0) series. For example, try to figure out what the maximum bit banging rate is on a Beaglebone Black. Good luck.

Getting up and running on an Eclipse/ARM/Segger toolchain sucks. No doubt. But you have to chew through it.

After that, it's about 3 lines to get an LED to blink.

</comment></comment></comment></comment></comment><comment><USER45> Maybe not the hardest part, but the most consistently annoying is that you are dealing with really low level issues, and you can't take anything for granted.

Memory allocation, compilers, threading, libraries etc. - you have to be careful at each and every step.

You're probably going to end up working with C or C++ - which is fine, and they are common enough, but you don't get a lot of nice 'VM-ish' things along with them.

You end up often having to know specific things about chipsets etc..

It's great because you 'learn a lot' and will come out a better Engineer - <USER2> sometimes that knowledge can be arcane.

You'll spend a lot of time doing things that 'everyone else' in software takes for granted and it can make it feel like you're moving slowly.</comment>


Leaked: Cambridge Analytica's Blueprint for Trump Victory - <AUTHOR> https://www.theguardian.com/uk-news/2018/mar/23/leaked-cambridge-analyticas-blueprint-for-trump-victory <comment><USER2> OK, this actually makes me a little bit amazed at Clinton's hubris. Her campaign was so confident of victory it stopped buying prime advertising space on Youtube and Politico, among other sites. This immediately freed it up for the Trump campaign to buy and use in the last two weeks prior to the election.

Haven't read her post election book but I assume it neglects to mention this own goal.

</comment><comment><USER3> The Cambridge Analytica / Facebook story revolves around the issue of privacy, so it has a place on HN (even if it is a bit of a dead horse at this point).

However articles like these use the story as a springboard to write about other topics or push other agendas - many of them purely political and therefore out of place on this website.

Just my $0.02

</comment><comment><USER4> The article and Cambridge analytics seem to attribute a lot of credit to their ways. Was their impact larger than the Russian meddling, and if so, did Trump win through tactical methods versus foreign interference?</comment>


Introducing Solium v1 – a Linter for your solidity smart contracts - <AUTHOR> https://medium.com/solium/introducing-solium-v1-d2bd0a7fbfb <comment><AUTHOR> Solium is an open sourced, customisable linter for Solidity. Its initial version was released a year ago. Since then, we've seen it grow to be trusted by organisations like Aragon, Zeppelin & Augur to keep their code quality in check. After a lot of feedback from the community and discussion of the vision of the project, today we're upping the game with the release of v1 in Beta!</comment>


Here's How to Get Almost Anyone's Email Address - <AUTHOR> http://www.azeemkhan.com/blog/2015/4/28/how-to-get-almost-anyones-email-address

<comment><USER2> Another tip for finding programmers is to check github commit history. Sometimes the email isn't on the public profile, but is marked as a commit email.</comment>


Windows 8 to support ARM, System on a chip, architectures - <AUTHOR> http://www.microsoft.com/presspass/press/2011/jan11/01-05SOCsupport.mspx

<comment><USER2> I've noticed a lot of speculation about how they will translate code between X86, X86_64 and ARM. Well, the simple answer is not to translate at all. MS have been pushing managed code via things like Silverlight and .NET for some time. My tuppence worth: Windows 8 on ARM won't support legacy x86 code, but will run .NET, Silverlight and any other managed code shamalamadingdong it needs to run. I can see Windows 8 on x86 supporting legacy code, but just as 16-bit support is gone completely in x86_64 Windows now, I'm expecting no support for unmanaged x86 code in the ARM version.

Where all this gets interesting is with things like Mono and Moonlight. If MS goes down this route, they could really be exposed as Mono and Moonlight mature.

<comment><USER3> > Windows 8 on ARM won't support legacy x86 code, but will run .NET. I can see > Windows 8 on x86 supporting legacy code

Hmm, I don't believe so. That'd introduce fragmentation that Microsoft's typical users (mom and pop) should not have to deal with.

Also that'd be a pretty drastic policy shift for Microsoft seeing the pains they've gone to maintain compatibility with older software.

My guess is that, at the very least, Win8 apps running native code will be packaged into a universal binary of some sort. I find that half-hearted though, since it requires recompilation of the original software.

wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off.

<comment><USER2> > wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and > it'd be awesome if Microsoft pulls that off.

JITing x86 - ARM might not even be fully necessary for most modern apps. It might be possible to do some sort of interception and JIT-style translation for certain parts of code but it might also be possible to provide a DLL level compatibility layer as fallback. That way when DLL functions are called they're called natively, and the main module executes via JIT.

I'm not suggesting that would be easy, it'll be balls to the wall hard, but that's the only thing I that immediately springs to mind that wouldn't come with a massive performance penalty.

The fragmentation argument is valid and an excellent point to make, however we don't really know who this is being targeted at or the defined primary use cases at this point. If Microsoft can f _ck up the user experience so badly with Vista and Windows 7 Starter, they can f_ ck up the user experience with ARM and not worry too much. It might also be worth bearing in mind that if a recompile is needed, it's going to be in the next Visual Studio, which will support a lot more managed code features through the CLR than unmanaged code on x86_64 (by which I mean the CLR supports more languages and has fairly tight integration - if you use C++ in Visual Studio you're probably using less of Visual Studio overall than if you're writing ASPX in C#).

</comment></comment></comment><comment><USER4> There is the idea that Windows is such a terrible system that the only reason people are staying with it is that they need their legacy applications. It's not _entirely_ without merit, but for a lot of people and businesses, Windows actually works rather well.

The importance of x86 is overstated too. Many applications will be pretty close to a recompile away. There is of course the usual chicken-and-egg issue that all platforms have, but if Windows/ARM (WARM?) takes off, they _will_ be recompiled.

<comment><USER5> Enterprise LOB is almost all .NET and web now. Native apps are increasingly just consumer apps.

<comment><USER6> If Microsoft ported Office/SharePoint to native ARM I might be able to believe this.

<comment><USER7> They are porting Office to native ARM, it was mentioned in Sinofsky's presentation.

<comment><USER5> From the CES demo it appears that they've already done the port. I was really impressed they had IE9 with GPU acceleration on ARM working already too.

</comment></comment></comment></comment></comment><comment><USER8> Porting an OS onto a new box can be technically quite interesting, but is only a fraction of the aggregate effort involved.

It's the business issues that matter. Whether you can recoup the costs, and when.

Application availability, third-party support, hardware vendor support, testing, and whether there's enough of a draw (coolness, compelling price advantage, better battery efficiency, whatever) to pull your user bases to the new platform, and pull in new customers.

There's the additional risk with whether and when key vendors will move. It might well technically be a recompile and go for the applications, though the vendors of key applications are probably going to need to see a sufficient market, or they may want some funding for porting. Vendors tend to be (reasonably) loathe to accept this porting and testing and support load without some form of revenue plan.

Emulation and translation are technically possible, though that too can be problematic; various vendors can tend not to support emulated or translated code. For understandable reasons, more than a few vendors wouldn't support their applications on Windows on Alpha via FX!32, for instance.

I'm also surprised that Microsoft is discussing this now; whether this is a cudgel on some providers, a palliative for their partners considering adding other OS platforms (Android, WebOS or otherwise), customers that are accepting other OS platforms, or whether they're really (seriously?) talking about a project and a potential product that's two years out.

Wondering what their particular motivation(s) here might be, still.

</comment><comment><USER9> Interesting that Microsoft's answer to "Why?" seems to be "Because we can." by journalists. Hopefully they have a better strategy than that.

That said, I'm all for more ARM support in the world.

It looks like it will run .NET apps with little or no reworking. They probably borrowed a lot of the work of the .NET Compact Framework team for a reverse port. Expect native SDKs later, after the initial launch.

<comment><USER10> MS has learned from their experience with Windows on Alpha. Even when they released XP for x86-64, they initially wouldn't sell it at retail for fear that people would get confused and buy the wrong one.

I'm betting they have some compatibility magic cooked up that we haven't seen yet.

Emulation has already been suggested. How about the possibility of having a launch hook that recompiles x86 machine code to ARM machine code? MS is on the short list of companies with the necessary resources to pull that sort of trick.

<comment><USER9> Their "magic" is .NET and MSIL.They explicitly stated they aren't virtualizing or emulating x86 code during the session.

<comment><USER11> Right. They have ten years of .NET penetration into the corporate world, the web, and 3rd party application developers - plus four years of .NET integration right into their operating systems.

It is running on everything from embedded systems, to phones, to desktops, to clusters. Throw in that all the hardware vendors who are interested in "the Next Windows" and Microsoft has just laid out a roadmap for the next ten years.

</comment></comment></comment></comment><comment><USER12> So how long will it take hackers to get Windows 8 running on an iPad? Will definitely be interesting...

<comment><USER13> Why? Putting Android on the iPhone I get, but I don't see too many hackers out there wanting to flip off Apple by installing _Windows_ , of all things.

To put it another way, how many macbook pros are running Win7 solo, aka w/o bootcamp or VMware?

<comment><USER14> Why? For the sole purpose of getting Win8 running on an iPad.

<comment><USER13> Fair enough.

</comment></comment></comment></comment><comment><USER15> I wonder how much effort will be required to port native applications to Windows/ARM. I imagine it won't be too onerous since both x86/x64 and ARM are little-endian. Excepting bits of inline assembly and use of compiler intrinsics I don't think it would be too difficult. I also wonder if there will be a FAT binary extension to PE/COFF, or if applications will have to have separate builds per platform.

</comment><comment><USER16> So Microsoft sees a real threat in Chrome OS netbooks then?

That's the only place I see this being relevant. Windows in any form that can meaningfully execute legacy x86 code is not going into a non-PC device. (dashboard computers, pocket computers, pmps, phones, tablets, etc)

So the only thing left is netbooks. Is that really a relevant play in 2011? Do they think this _isn't_ a feature Google can match and beat them to market on? Do they think the legacy of Windows will be a compelling alternative to the relative simplicity and security of Chrome OS in that market?

<comment><USER17> I know that the "news" in this announcement is about ARM. But Soc itself is also about making existing PC software run faster. At the moment there is little argument for purchasing new hardware because multiple cores are failing to significantly improve actual performance of desktop apps for reasons with which we are all familiar.

</comment></comment><comment><USER18> Can one of you clever people explain what is meant by the term "system on a chip"? Is it just a marketing buzzword, or is there more to it than that?

I've tried wikipedia, but just got even more confused.

<comment><USER19> A system on a chip is a single chip that integrates all or almost all other chips on a motherboard into one chip. So this chip will have a cpu, graphics, memory controller, network controller, io such as usb. That way you can have basically one chip that is all or most of the computer. Sometime RAM and normally storage is separate chips but you basically end up with just a few chips on a very small, normally low power motherboard. It is great for system integrators as they don't need to spend as much development time to build new machines.

<comment><USER20> It's also great for power and size constraints.

</comment></comment></comment><comment><USER6> If this is true, then Windows 8 is not a true successor to Windows 7. Current desktop/server apps assume binary compatibility with x86. This sounds much more like a scaled-up version of Windows Phone.

<comment><USER21> That's a crazy thing to say. The UI, the APIs, etc. will all be based on Windows 7, and any all-CLR apps should run without change. On Windows 8 running on x86, current apps (and Windows 3.1 apps, and maybe DOS apps?) will undoubtedly still run.

It's just like the Mac Intel transition, but without an emulator to fill in the gaps.

<comment><USER22> Who knows? MS might be obsessed enough with backwards compatibility to pack an emulator in there, like they did with WOW64 (though it would be more difficult to write an x86 emulator for ARM).

<comment><USER23> > it would be more difficult to write an x86 emulator for ARM

Building an x86 emulator is easy. Building one that can run Windows 8 software at speeds comparable to then current Intel or AMD x86 processors will probably be impossible. There is no such performance gap between ARM and x86.

<comment><USER24> Would the opposite be easier? It might make sense to offer comparability for Windows|ARM executables on Windows|x86, so if you want to hit both platforms, you'd be doing it in ARM.

I can see ARM being great for corporate desktops: .net LOB apps work, IE will work, Office will work etc.

<comment><USER23> Sure, but one key advantage of Windows is that it has a huge legacy of software that already targets x86 and that would have to be recompiled/reoptimized to ARM.

The performance of a built-for-speed x86 is very forgiving. Eclipse runs well enough on my Core i5, but I suspect it would have problems on an energy- efficient ARM.</comment></comment></comment></comment></comment></comment>


Google's New Social Network: iGoogle - <AUTHOR> http://googlesystem.blogspot.com/2008/04/googles-new-social-network-igoogle.html <comment><USER2> I'm of the mind that Google should build a social network around "Googling" someone. If they can capture that behavior, their install base would be huge.

<comment><USER3> That's actually a brilliant idea, IMHO.

</comment></comment><comment><USER3> I'd like to take this opportunity to plug our social network customizable homepage, ClutterMe.</comment>


Ask HN: Help finding a consultant/contractor - <AUTHOR>

I am a front end developer myself but I am at a loss here so what better to do than ask the HN community.
I have a family friend who is a serial entrepreneur and has several accomplished businesses in the physical goods realm. He and a couple other guys are teaming up to venture into the technical world (more specifically digital audio on the web). They have absolutely no technical expertise.
I am trying to put them in touch with a reputable and reliable firm that can provide folks that act as product managers and steer them in the right direction and one that also has a reputation for good reliable code that can be maintained over the long haul.
They are well bankrolled (can drop 100k+) and prefer to deal with firms only in the U.S. What advice or references would you provide for someone in their situation?
Thanks all
If you prefer private email, see my profile. <comment><USER2> They really need an invested co-founder with technical experience. A consultant can help but really doesn't have the right incentives.

<comment><AUTHOR> Thanks for the response. That was my initial advice was to hire programmers full time and give them skin in the game via substantial equity.</comment></comment>


Why does soap work so well on the SARS-CoV-2 - <AUTHOR> https://twitter.com/pallithordarson/status/1236549305189597189 <comment><USER2> It works well because apart from washing the virus away, soap denatures its envelope, the little "bag" that actually contains the virus.

That envelope is made up of lipids. IE, molecules of fat. Soap+water dissolves the envelope, so the virus is inactivated.... to infect anyone, it needs the envelope to be present.

Link:

[https://www.marketwatch.com/story/deadly-viruses-are-no- matc...](https://www.marketwatch.com/story/deadly-viruses-are-no-match-for- plain-old-soap-heres-the-science-behind-it-2020-03-08)

</comment><comment><USER3> Does it? Or is it just all about washing the viruses away? I tried to get a definite answer and ended up with a whole lot of opinion.

<comment><USER4> Did you read his entire thread? There are 39 tweets that seem to cover the details pretty well, including the chemistry behind his statements. This link makes it easy to read the whole thread. [https://threadreaderapp.com/thread/1236549305189597189.html](https://threadreaderapp.com/thread/1236549305189597189.html)

<comment><USER3> It is fairly well known that the class of viruses that the coronavirus belongs to is fairly fragile. I think my question comes down to; does soap actually make any real difference in a case where almost everything destroys the virus? The only viruses that survive are pretty much only those that are embedded in some other substance. That would mean that the discussion on Twitter about soap coming intro direct contact with the virus was pointless.

One source suggested that the reason that soap is better was simply because it caused people to wash their hands for longer.</comment></comment></comment>


Bethesda claims to be anti-DRM - <AUTHOR> http://www.bethblog.com/2015/04/27/why-were-trying-paid-skyrim-mods-on-steam

<comment><AUTHOR> Such claims are very questionable however, since they didn't release any of their games on GOG so far.</comment>


Richard Buckland's UNSW Computing 1 - learn with games, puzzles and friends - <AUTHOR> https://www.openlearning.com/courses/unsw/computing1

<comment><USER2> Nice, Richard is the best lecturer in CSE. I miss my COMP1 days

<comment><USER3> Agreed, I'm sure this course will be as great as his lectures were/are. Stoked to see his name randomly pop up on HN.

</comment></comment><comment><USER4> This is really exciting. OpenLearning looks like it's really going to give the other learning websites a run for their money too.

</comment><comment><USER5> can't wait to take the course!

</comment><comment><USER6> Programming in C! How encouraging for the beginner! Why not ruby?

Look, astrophysics has a word for spots on the sun. Sunspots. Meanwhile the most fundamental molecule of life is deoxyribonucleic acid. That last word is a product of the classic education system which encouraged "gentlemen" (today: "engineers") to study Latin and Greek.

Now I'm not discouraging the teaching and book-printing of rudimentary languages like C and Latin, but maybe C (and Latin) aren't meant to be learned today by beginners in a conversational manner. Students who are curious will naturally look back to ancestor-languages (I have books on C and Perl now as a ruby programmer). For Latin and Greek we have sites like etymonline.com, which are great.

What is it with you guys? Are you worried that once the newbies go ruby they'll never go back? Back where? We all need to evolve as developers. Haha soapbox I apologize. I like C syntax.

<comment><USER4> I think much of this course is also about "under the hood" - what's going on at a memory level, and fun things to do with microprocessors to get an understanding of the whole shebang. I think if you can be taught to get good grasp of the execution stack, heap memory and pointers, then teaching yourself ruby, python, or any other more abstract language would be a breeze.</comment></comment>


Introduction to the practice and philosophy of knowledge graphs - <AUTHOR> https://humansofdata.atlan.com/2019/08/reconciling-your-data-and-the-world-with-knowledge-graphs/ <comment><AUTHOR> Hi HN,

I'm interested in the possibilities that graph data structure provides and strongly believe that it has a bigger role to play in the future of software engineering and data analytics. Knowledge graphs are a great example of graph technology in practice.

I wrote this article with the intention to provide an introduction to this fascinating topic and hope that you find it useful.</comment>


Stopping Computer Crimes (1989) [pdf] - <AUTHOR> https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19920002439.pdf <comment><USER2> See also

[http://faculty.nps.edu/dedennin/publications/ConcerningHacke...](http://faculty.nps.edu/dedennin/publications/ConcerningHackers- NCSC.txt)

[http://faculty.nps.edu/dedennin/publications/ConcerningHacke...](http://faculty.nps.edu/dedennin/publications/ConcerningHackers- Postscript.txt)

by Dorothy Denning (a computer security expert who is also married to Peter Denning). (Both of them published quite a bit on this topic in this timeframe.)

</comment><comment><USER3> Anything that me mentions Cliff Stoll's the Cuckoos Egg has to be worth reading.</comment>


Android is the most stable mobile OS, says new report - <AUTHOR> http://www.digitaltrends.com/mobile/android-stable-mobile-os-says-new-report/#!B3cZg <comment><USER2> I have heard from many non-techie iOS users that iOS 7 is a buggy mess. I take that to mean that everyday users see the manifestations of bugs and that the bugs are obvious and annoying.

Among the two most mature OSs, the apparent fact that iOS 7 was a buggier release than iOS 6 might be what's making Android look relatively good.

</comment><comment><USER3> Suure, from a website called 'Crittercism', whose investors include Google Ventures. I'm usually not skeptical, but I had a weird feeling.</comment>


Testing Firefox more efficiently with machine learning - <AUTHOR> https://hacks.mozilla.org/2020/07/testing-firefox-more-efficiently-with-machine-learning/ <comment><USER2> This is the kind of article I'd love to read more of, as in more of each bit! It allowed me to discover the very well made docs to contribute to Firefox[0], which feels very welcoming to an enthusiastic non-genius-expert engineer, who happens to have some experience with CI, testing automation, and a couple languages.

I assume the overhead of the project (and subsequent tweaks to model, re- training and validation) is sufficiently negligible compared to the measured benefits even if those weren't as clear-cut as 70%. I'm unaware of how much compute is required for the task, but likely less than many compute-years per day :)

One thing I did not notice in the approach to the modelization of the problem is any link/tag regarding the platform for which the code changes are made, and the programming languages used. There seems to be some evidence that certain languages could lead to more defect fixing commits[1], and I don't know if there's evidence that some platforms are more prone to bugs (I'm sure wars of words have been fought over this). But would it make sense to have that sort of information inform the model in a way? I fully understand that I might be out of my depth here.

[0] [https://firefox-source- docs.mozilla.org/setup/index.html](https://firefox-source- docs.mozilla.org/setup/index.html)

[1] [https://cacm.acm.org/magazines/2017/10/221326-a-large- scale-...](https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study- of-programming-languages-and-code-quality-in-github/fulltext)

<comment><USER3> Looking at the code ([https://github.com/mozilla/bugbug/blob/master/bugbug/model.p...](https://github.com/mozilla/bugbug/blob/master/bugbug/model.py#L184)), they test for any significant words in the code, comment, commit message, tags, etc.

I wouldn't be surprised if language is explicitly included as, for example, a flag in the "data" object. But the model should be able to figure it out by itself otherwise by identifying keywords that only some languages (often) use.

</comment></comment><comment><USER4> Fantastic read. My only concern is that there wasn't any talk around cost of false positives (selecting a test to run where it is unnecessary) vs false negatives (incorrectly dismissing a relevant test), as those costs in terms of their effect is not symmetrical.

The cost of a bug slipping through because a test being skipped will be higher than running an irrelevant test to a commit.

<comment><USER5> There isn't any discussion of the cost at all. It just says the test run rate is down by 70%, it doesn't say anything about the defect detection rate, even though they say this is their cost function.

10 core-years per day sounds like a lot but it's only about a 10kW load, and they've saved 70% of that, or about $20 of opex per day.

<comment><USER6> Is that really all? That would be 3650 cores running full time. 3W per core sounds too little for power consumption. And do power costs really dominate the price of running CPUs? I'm guessing the savings here are at least one order of magnitude more than your $20/day.

I get about $1000/day based on some EC2 prices for typical machines I've used, though I'm sure Mozilla's requirements are different and they can negotiate better prices than I can.

<comment><USER5> I probably missed a few factors, but I just hate a blog post that uses big- sounding numbers when they aren't big.

<comment><USER7> Big for who? Hundreds of machines running constantly is big for me.

</comment></comment></comment></comment></comment><comment><USER8> Similar work done at Facebook: [https://engineering.fb.com/developer- tools/predictive-test-s...](https://engineering.fb.com/developer- tools/predictive-test-selection/)

</comment><comment><USER9> I always thought software/gui testing would be a great application for ai, although I've never really sat down to think about how it could be done

<comment><USER10> Check this one out: [https://mesmerhq.com/](https://mesmerhq.com/)

It's for mobile apps mostly though.

</comment></comment><comment><USER11> similar work at google: [https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...](https://www.google.com/url?sa=t&source=web&rct=j&url=https://research.google.com/pubs/archive/45861.pdf&ved=2ahUKEwjq- ay_2sXqAhWSzDgGHZ6mB8IQFjAHegQIBhAB&usg=AOvVaw1XsFJdUcbLPk1oFl9HxWtD&cshid=1594488052487)

<comment> just-ok URL without redirects & tracking IDs: [https://research.google.com/pubs/archive/45861.pdf](https://research.google.com/pubs/archive/45861.pdf)

</comment></comment><comment><USER12> Interesting. So for training they use features:

> In the past, how often did this test fail when the same files were touched?

> How far in the directory tree are the source files from the test files?

> How often in the VCS history were the source files modified together with > the test files?

But for prediction all they input is a tuple (TEST, PATCH), and XGboost works fine without the additional features?

<comment><USER6> I think they're deriving the additional features at prediction time. The test and patch don't contain all the information you need to compute the features, but they contain sufficient information when combined with a big static lookup table. At least that's the way I read it; agree it could be clearer.

</comment></comment><comment><USER13> The most interesting part of this to me was something tangential: they use Redis Queues. Anyone have experience with this? Good or bad impressions?

The documentation is tantalizing, but hilariously short: [https://devcenter.heroku.com/articles/python- rq](https://devcenter.heroku.com/articles/python-rq)

Very "And then draw the rest of the owl." Oh really, you can just do `from utils import count_words_at_url; q.enqueue(count_words_at_url, '[http://heroku.com')`](http://heroku.com'\)`) and presto, your blocking function -- whose source code exists locally -- is run successfully at the other end?

I'll have to set aside some time to try this out. Python _does_ have introspection facilities that could make that possible. I could imagine that since the code is executed on the same box, it's relatively simple to send a request like "here's which module the function was loaded from; here's the order all modules were loaded in; load those modules and call this function." But it leaves so many questions: serialization, performance, scaling, and all the tiny bugs that inevitably come up.

I guess I was hoping someone could give me a quick gut check of positive/negative reactions. The full RQ documentation is slightly better: [https://python-rq.org/docs/](https://python-rq.org/docs/) but has some worrying signs:

 _Make sure that the function call does not depend on its context. In particular, global variables are evil (as always), but also any state that the function depends on (for example a "current" user or "current" web request) is not there when the worker will process it. If you want work done for the "current" user, you should resolve that user to a concrete instance and pass a reference to that user object to the job as an argument._

Yes, sure, global variables are the root of satan, but they're also a fact of life in many scenarios.

Interesting approach... I wonder how much of a nightmare it makes devops...

<comment><USER14> I've used it a bit in production. Our use case avoided a lot of the potential issues you mentioned, so it may not be entirely helpful:

* serialization: the input was passed a json string argument. the output was a file uploaded to S3, so just the URL was returned, again in a JSON string * global variables: the program was quite self-contained: there was an initial state setup that was not mutated afterwards. So RQ's fork-exec model(the default) worked well enough

Sorry I don't have much to say about performance and scaling. It was quite fine for our needs, and we could scale horizontally upto a certain point by just starting extra processes, and beyond that with more VMs. Since they all listened on the same RQ, it worked fine. (the number of items in our queue never really hit any of Redis' limitations either)

RQ lets you customize the worker model: so you could for instance use threads instead of processes.

Regarding monitoring: there's RQ dashboard[1] which gives a nice web interface to view jobs, failures, and restart them.

1: [https://python-rq.org/docs/monitoring/](https://python- rq.org/docs/monitoring/)

<comment><USER13> Thank you very much for the detailed response :) I really appreciate the thoroughness; it convinced me to use RQ.

<comment><USER13> +1 datapoint in favor of rq: [https://twitter.com/sdan_io/status/1285687026386444288](https://twitter.com/sdan_io/status/1285687026386444288) was built with it.

</comment></comment></comment></comment><comment><USER15> Stability and speed from Firefox are always welcome. I'd love to see some performance gains on armhf (raspberry pi 4) in particular. It's good, and close to being blissfully simple.

<comment><USER16> Wouldn't you run arm64 Debian rather than armhf Debian on the RPi 4? I haven't used the RPi 4 in a long while so I don't remember. But it seems weird to me that what you said would be the case.

[https://stackoverflow.com/a/48954012](https://stackoverflow.com/a/48954012)

[https://www.debian.org/ports/#portlist- released](https://www.debian.org/ports/#portlist-released)

<comment><USER15> 32bit armhf is still the "supported" way of running Raspberry Pi OS. I believe the 64bit build is on the horizon, but still considered beta.

If the consensus is its stable enough to give it a go though, I'll give it a go.

</comment></comment></comment><comment><USER17> really cool project. nice high-level overview of all the components. However, I still don't understand the impact measurement -- how do you measure the impact of this against the baseline? I didn't get that part in the effectiveness section. Maybe I'm too newb -- but you could A/B test this, right? 50% of PRs are subjected to automated tooling, 50% manual and compare compute cost and failures b/w the two?

<comment><USER18> That's what the shadow scheduler is measuring. If you run a superset of the AI- scheduled set, you can compute how well the AI is doing. Even if you don't run a superset, you can infer the results from following test runs (on a tree with the changeset in question, plus a few more, applied. You just have to be careful to make sure you don't blame later breakage on your changeset.)

</comment></comment><comment><USER19> yesss</comment>


When TDD Doesn't Matter - <AUTHOR> https://www.facebook.com/notes/kent-beck/when-tdd-doesnt-matter/797644973601702

<comment><USER2> It is good to see a respected teacher and theorist of the agile movement making the point that good judgement is preferred over dogmatic adherence to a set of principles.

</comment><comment><USER3> Apparently this was posted a year ago, which is kind of frustrating for me because it's exactly the sort of analysis I've been hoping for since I was first introduced to TDD.

I'm not really comfortable with the space that he's constructing, but at the very least it's a space. Like if you had a bunch of requirements you might be able to actually determine if TDD makes sense via somewhat objective criteria instead of via whomever makes the best appeal to pathos.

What I actually want (and have been working on creating) is some sort of problem space[1] that allows you to analyze any given problem such that you can determine whether TDD will benefit or harm the development and verification of a solution.

[1] - It looks suspiciously like a general purpose problem space is kind of a ridiculous thing to try and define mathematically. I've had to set my sights a bit lower than my initial goal, but the ultimate dream would be objective analysis based off of high level discussion of what the stake holders want.

<comment><USER4> I feel like you get a feel for this as you grow gray. 98% of the code I write is not tdd.2% is instant tdd and I am happy for those times.

Things that make the tdd cut for me? Writing an algo. Maybe a maze solver. Maybe a payroll tax calculator. Maybe a monthly bill calculator.

I want these parts of my system rock solid, and it is super easy to make wack a mole where you fix one bug to regress a previously fixed bug. Love very solid TDD tests here.

Other 98% if my app? No way. Tdd adds cruft and can steer you to local maxima aND away from the optimal solution.</comment></comment>


What's the point of HN? - <AUTHOR> Is HN for discussion? If it is then why are dissenting opinions, that are well made and not troll-like, down-voted. Moreover if down-votes are intended to indicate only dissent (as I've been informed), not indicate low value remarks, then why is it considered beneficial to fade out such remarks.
Is HN supposed to be a sounding chamber or is the idea to foment useful discussion? Perhaps instead it's primarily just a link sharing tool?
The main stimulus to my question is how time and again good comments [that often I disagree with] are down-voted (presumably, vote numbers are hidden of course). Then the site admins deem that these comments need to be made difficult to read. This suggest that high-value discussion is not the point of the site; instead it serves to establish a narrow consensus and silence other voices.
So what is HN for? <comment><USER3> It's where hackers come to share and shoot the shit. It used to be somewhat more welcoming and friendly when it was small. But it's grown like 1000x since those days. YC is working on it.

</comment><comment> jack-r-abbit Yes, there is a certain amount of hive-mind here and with certain topics you are best to not go against this groupthink if you value your karma. But since karma doesn't really have any value (beyond unlocking additional features) you should be able to speak your mind even if it is unpopular. Down-voting is not meant to be for well formed opinions you disagree with... but it does happen. More often, down-voting is for comments that are off point, personal attacks, general rudeness, and other things that are bad form.

<comment><USER4> It should be noted that there's a big difference between an unpopular opinion and a _misinformed_ opinion, the latter of which typically causes downvotes depending on tone.

I rarely see super-gray posts for going against the grain.

<comment> jack-r-abbit Some topics are worse than others. Threads about Snowden or piracy are usually littered with grey posts that go against the ideas that Snowden is a god and piracy is just fine.

<comment><USER5> Another one I found is that advocating for privacy is a quick way for downvotes. Lots of users here run businesses that thrive on user-generated data so it makes sense they would prefer more control and liberty with the data in their service, to the dismay of some users/consumers.

</comment></comment></comment></comment><comment><USER6> You make a mistake when you say downvotes are only for disagreement. Some people do not use them for disagreement and only ever use them to indicate unsuitable posts.

<comment><USER7> I would agree - I would be horrified to find people down voting because they disagreed with a statement of position or opinion.

Downvotes indicate the comment is not part of a constructive conversation. We all want to find places where we can be heard and part of that price is listening to others. If you can't do both, you can't be part of a conversation.

<comment><USER6> > I would be horrified to find people down voting because they disagreed with > a statement of position or opinion.

Eh, I'm not bothered if people downvote to disagree. I'd rather they did that than bickered at me.

<comment><USER7> That's because karma points aren't important. What if the downvoted were written in the anti-union blacklist handed round the mine owners, or added to the security clearance files or ...

Open transparent discourse.

</comment></comment></comment></comment><comment><USER8> It's a forum where people can post their hard work, and the rest of the community can poke holes in it and leave snarky comments.

Or a techy/nerdy link aggregator, maybe?

<comment><AUTHOR> ... and if people disagree with someone's well made snarky comments do you think that the site should try and make those comments hard to read?

</comment></comment><comment><USER9> The underlying point of HN has always been contribution.

Sure, that's a terribly bold assertion for me, a regular nobody, to make, but it's how I've always seen HN. Since this is the open Internet, I'm sure there's someone who will tell me that I'm wrong, or down-vote me because they disagree, but I'm fine with dissent. Dissent and disagreement are the price of admission when we voice our opinions.

My personal opinion is mostly useless outside of a rare few places where I happen to have some experience. The important thing I try to remember is HN is full of people with a great deal more experience than I have in particular fields. I try to learn from their contributions, so I really do appreciate their efforts. One of the possible ways they contribute is by down-voting me or stating their disagreement with me. Either way, I learn something new, so I still appreciate their efforts.

If pg replied to me and told me that I got it all wrong, and I got clobbered with a bazillion down-votes, then I'm the person who just learned something new, albeit the hard way. Everyone else also gets to learn from my rather public mistakes.

Those funny little up and down vote buttons exist for good reason, but how to use them has never formally been defined (to my knowledge) by any of the people running HN/YC. The complete lack of defining usage has always seemed to be entirely intentional; with every feature of HN, you are expected and trusted to use it wisely. You are being trusted with privileges of voting, flagging, submitting, and commenting. If you abuse the trust and the privileges, you'll lose them.

All people suffer from the same delusion; we believe our own interests are interesting to others. When you try to make a contribution of something interesting and useful, and you miserably "fail" by all noticeable metrics like points, then once again, you learn something new. I can honestly say that _my_ interests are rarely interesting to others. If you don't believe me, go look at the "submissions" link in my profile to prove the point. Though you can't see the point counts on my comments, I'll openly admit that my comments fare no better than my submissions. If take a look, you'll see that I "fail" regularly, but I keep trying to contribute useful and interesting things.

An important number to look at is the "avg" in the user profile. It is the average score on comments you make. The default value for each comment is 1, an "avg" below one means your comments are a hindrance in the eyes of your fellow HN contributors, and an "avg" above one means your comments are successfully contributing to discussions. If your "avg" is about 2, then on average every time you comment, at least one person appreciated the effort of your contribution, and put in their effort to up-vote your comment.

Check out the avg for the HN user grellas [1]. Every time he puts in the effort to type one of his infamously fantastic comments, at least 53+ people appreciated it (and remembered to scroll back up and give him an up-vote ;-). Even if you disagree with him on something, you can still appreciate the effort he put into his contribution, and the experience and expertise behind his opinions...

Yes, you can disagree with someone, and still appreciate their effort enough to return the favor in kind with your up-vote. Since there are no rules or guidelines on voting, you're free to use your votes wisely.

I tend to lack useful experience and expertise on most subjects, so all I have is my generally uninformed opinions. Some people in my position will sit quietly and learn from others, but other people in my position will try to become informed enough to ask good questions. A good question is a contribution. I doubt the good questions get up-voted as much as the deserve since most of the attention goes to the person who shows up with a good answer.

I _really really try_ to remember to up-vote the good questions, but I'm sure I forget more often than not. Just like everybody else, I'm regularly distracted by the good answers, and after reading the good answer, the good question always seems less useful. I'd bet there's some cognitive bias at work in all this, but sadly, I can't name it.

Sometimes good answers are opinions backed by experience and expertise, but other times good answers are backed by references. I'm just a sucker for up- voting answers with references, in fact, I scan for them.

Down-votes happen to everyone, so learn what you can divine form the experience, and let it go. It's just a fact of life that _someone_ on the Internet will probably disagree vehemently. Also, mistakes happen in voting, and there's no way to correct your own voting mistakes.

The down-voting feature is a privilege you earn. I've always been strongly in the "up-vote-the-good-stuff" camp, so something needs to be fairly egregious for me to down-vote it. For me, vehemently disagreeing is never enough to warrant a down-vote. There needs to be some aspect of malice. The same is true and to a higher degree for flags. Just like everybody else on the planet, I've got a lot of practice being wrong and uninteresting, so I try to be tolerant with others.

The site moderators do not make the down-voted comments fade, the HN forum code [3] running on the server does this automatically. The mods get unfairly blamed for a lot of things they don't actually do, and most of the misplaced blame is due to users not understanding or studying the available forum code and docs. HN was originally written as a test of a new programming language called "arc" [4], but most users are unprepared to invest the time to learn a new language and understand the forum code base. I am fluent, well, was fluent, in a few related Lisp dialects, and I've only put in the time to barely scratch the surface of how the HN forum code really works. The only person I have to blame for not knowing all the details is myself.

A primary problem with all discussion forums and user supported link aggregation sites is the endless competition for both the attention and effort of others. Most of the HN Guidelines [2] can be written as a single guideline, "Don't be the jerk begging, baiting, or manipulating others for their attention and effort."

If you're like me and reliably "fail" at contributing useful and interesting comments and submissions according to the flawed metric of points, then you still ought to be happy. You tried to contribute, and you had the courage to put your own interests out there for others to judge, but far more importantly, the lack of points also implies the lack of using attention grabbing engagement tactics, so you just succeeded at staying out of the endless fray of countless attention seekers.

If linkbait outrage porn or regurgitation reporting is far more popular by the metric of up-votes over time, then I'm actually grateful that my interests are elsewhere. It just means I have a much better chance to contribute something different, unexpected, and hopefully interesting.

Lastly you get the references, but please realize they are not intended to support my personal opinions. Those are my own, and right or wrong, I hope they're useful and interesting for you and everyone else.

[1] [https://news.ycombinator.com/user?id=grellas](https://news.ycombinator.com/user?id=grellas)

[2] [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[3] [https://github.com/HackerNews/HN](https://github.com/HackerNews/HN)

[4] [http://arclanguage.org](http://arclanguage.org)

<comment><USER10> I don't think anyone who takes issue with the fading-out of downvoted comments (like myself) thinks the mods are doing that directly. Rather, the effect makes no distinction between downvotes for mere disagreement (which are allowed anyway, but I think shouldn't be) and downvotes of rude/spam/obvious low quality posts, etc. In other words, there is as much a spectrum of quality for downvoting and upvoting as there is for commenting.

The effect takes what is, in essence, a purely subjective subset of user opinions and applies it against a user as a global censor. While the effect does appear to converge towards what is probably a correct result over time (in that correctness implies consensus opinion), the complete lack of context combined with stifling the visibility of discussion seems to be both heavy- handed and unfair.

Bear in mind, also, that text posts are faded by default, because pg assumed allowing users to post long form content would only lead to them using the forum as a blog. This suggests an almost antagonistic attitude towards user participation which is offputting to say the least.

<comment><USER9> We don't really know why text-based submissions are faded by default, or more accurately, I don't recall pg ever saying why it was done. On the other hand, we can obviously see the effect fading of reducing emphasis, and from the HN guidelines we know attempting to attract attention is discouraged.

A text-based submission puts the words of the author at the very top in a prominent and unfair position for attention. The very slight fading of the those unfair top-most words has always seemed to me to be an attempt to compensate for the prominent position they get by default. I could be wrong, but it just looks like a way to make the playing field a bit more fair while still allowing a discussion to be started with text alone.

As for favoring link-based submissions over text-based submissions, my guess for the reason has always been sitting in the title of the site; "News," whether the original name, "Startup News," or the new name, "Hacker News." The term "News" implies "new" and the time-based ranking techniques are an attempt to keep the "new" stuff where it will be seen. In other words, "new" gets more emphasis and prominence.

Calling the fade effects on comments "censorship" seems a bit unfairly rhetorical. If someone wanted to reverse the rhetoric to make the feature seem unfairly beneficial, they'd call it "curation" instead. Either way, the fading does reduce emphasis and prominence, but the same is true for all the ranking and other aspects of the site.

If a dissenting opinion is well written but was "unfairly" down-voted in your opinion, the fade effect gives you the needed feedback to take the "needed" corrective measure of up-voting it to compensate. It may not be a perfect system, but it's still much better than bias and competition issues caused by displaying per-comment points.

Though how to use up and down votes have never been formally defined, their use has never been "purely subjective" since the terms "up" and "down" and even "flag" still have general but vague meaning. Maybe I lack the needed imagination, but I simply can't imagine a regular person using an "up" vote to indicate disagreement, disapproval, opposition, annoyance, discouragement, or punishment.

<comment><USER10> FWIW here is pg personally stating the reason for text submissions being faded out: [https://news.ycombinator.com/item?id=468231](https://news.ycombinator.com/item?id=468231)

I think it is censorship, but i'll concede it's weak censorship and that plenty of users seem to be ok with it, which is valid. You're right, that one person's censorship is another person's curation - though I would personally go a step further and say that curation is a subset of censorship, without the negative connotations. Whether it is or not depends on whether you agree with the net effect.

>A text-based submission puts the words of the author at the very top in a prominent and unfair position for attention.

I guess we would disagree here, since I don't believe it is unfair. The prominence of the author's post is the entire point of a text post - <USER2> author is asking a question or presenting a product or something, and the rest of the thread is a reaction to that (or reactions to reactions, etc.) It's implicit to the medium that the tree has a root.

Reducing legibility and reducing prominence are two different things, at least to me. I have no problem at all with upvotes or downvotes affecting where subthreads wind up in the sorting order - that's precisely what they should do. But why also make content more difficult to read as well?

If anything, that makes those elements more prominent, as it send a visual cue that "this is something you can easily ignore as it's not worth your time," which may not be the case.

Keeping comments and text posts legible forces people to actually read the content, consider it on its own merit and act accordingly (downvote, upvote, ignore, respond, whatever). It encourages conversation rather than the creating of filters to stifle it.

<comment><USER9> Great find on the pg link on the text-based submissions. We agree on how text- based posts need to put said text prominently at the top. It just wouldn't make sense otherwise. From the link, it seems the point of slight fading the text-based submissions slightly was to discourage the text-based submissions and also distinguish them from regular comments.

You also have a point regarding legibility. Since faded text is still readable to me, I hadn't thought of it in terms of legibility. Reduced legibility does result in requiring increased effort, and many people simply won't bother. The real trouble with "legibility" is it's highly subjective due to depending on both the type and configuration of the system hardware being used, and the eyesight of the person attempting to use it. Though most things try to be usable for people with "average" eyesight, there are actually countless combinations of human visual capacities, advantages, impairments, and preferences.

Since all we ever know is how our own eyes see things, we often forget how the exact same thing can be vastly different for others. I might be able to see the faded text a whole lot easier than you can, or vice versa, so faded text could be extremely annoying for one, but only be trivially inconvenient for the other. When I caught myself wondering if your system was configured "correctly," the supposedly "obvious" finally dawned on me; it's probably a whole lot easier for me to read the faded text than it is for you, so our difference of opinion could very well be due to being unable to literally see things the same way the other does.

If faded text is extremely annoying and difficult for you to read, then please contact me through email. I know great deal about accessibility issues and configuring systems/software to adjust for many different types of eyesight impairments and idiosyncrasies.

<comment><USER10> No, you don't understand - it's not a usability issue for me, I can see it fine. Actually better than fine because i wrote a userscript for myself which undoes the effect anyway, so even dead posts come up in black text. I apologize if I gave that impression.

It is actually kind of an ethical issue for me. It doesn't matter that the initial effort to read the faded text is minimal, but that the site is putting that extra friction there to begin with. Users should be able to judge the quality of posts and comments on equal terms, not have the site predispose them to dismiss certain posts based on what may be an irrational metric.

I understand that it's probably not a popular opinion and it seems like a minor and petty thing but it just bothers me. I'm not going to push it, though, i'm sure it already seems like i'm ranting.

<comment><USER9> It didn't seem like ranting to me. I think you did a great job of expressing your opinion clearly and fairly. In a mostly failed attempt to empathize, I brought up the vision/display issue as a possible reason why the fading might bother you more than me. Normally, I need to use a specialized browser to prevent headaches and it never renders the fade effect, so as saying goes, "Out of sight, out of mind." I can only withstand black text on a white background for a few hours, but then I'm pretty much toast and in dire need of some aspirin.

Oddly enough, over the last two days I've been once again working out the needed css to override handling of a few corner cases on HN, so for a change, I've actually been seeing the fade effect. The fade _is_ annoying, but on the bright side, it did enable me notice a few unfairly down-voted comments, and prompted me to give a corrective up-vote.

The one unfairly down-voted comment sticking in my memory was some person saying they didn't like Debian distribution of Linux and cited the 2006 OpenSSL fiasco as their reasoning. Down-voting a general opinion, and particularly one with factual support, is simply abusive voting, but sadly, it happens quite often on HN. If you know how to stop fanatics from doing dumb and/or mean things with their votes, then I'd love to know the answer. The only solution I know is to up-vote against them (when I notice the down- votes).

You said you've already solved the issue for yourself with a "userscript" but whether that's through GreaseMonkey or through leveraging userChrome.js is uncertain. It's actually much easier and cleaner to fix the display with pure CSS, either through a plugin like "Stylish" (chrome/firefox), or through your userContent.css file.

For me, I'll probably use something like the code below since I want the down or dead comment to be displayed equally like all the other comments, but I also want some form of feedback to let me know the comment was down-voted.

      @-moz-document domain("news.ycombinator.com") {
        /* down-voted comments, reset font color to black */
        font[color="#5a5a5a"],
        font[color="#aeaeae"] {
          color: #000000 !important;
        }
        /* down-voted comments, add trailing indicator of down-votes */
        span font[color="#5a5a5a"]:last-child::after,
        span font[color="#aeaeae"]:last-child::after {
          color: #aeaeae !important;
          white-space:pre;
          display: inline !important;
          content: '\A\A [down?]' !important;
        }
        /* dead comment class, reset font color to black */
        .dead, .dead * { color: #000000 !important; }
        /* dead comment class, add trailing indicator of down-votes */
        .dead:last-child::after {
          color: #aeaeae !important;
          white-space:pre;
          display: inline !important;
          content: '\A [dead?]' !important;
        }
      }

The above sort of turns the tables (if you pardon the HTML tag pun) by changing the comment font color to black, and adding a subtle trailing text indicator of "[down?]" or "[dead?]" that's mostly faded out. It should level the playing field, but still give me some gentle feedback so I can make a corrective up-vote when needed. As always, it's not a perfect solution, but it seems like an improvement.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I believe that HN is an open forum that wants to be a closed forum. It appears to have been designed around the principle that a singular, consistent concept of "quality" exists, primarily due to the homogeneous nature of the original community, and the assumption that this community would likely find only a narrow subset of topics relevant.

Fading out remarks is one example of such a bias in effect - were there only one type of poster and, predictably, one set of qualifiable opinions on HN, then the effect of censorship from a single user downvoting another and rendering their comments more difficult to read could be construed as acting on behalf of the community's standards as a whole, rather than reinforcing the bias of a particular subset or group.

Although some faded comments are obvious trolls, rudeness or spam, disagreement for any reason (spoken or otherwise) leads to globally visual censorship. Arguably, the more faded a comment is, the more 'justifiable' that censorship can be, in terms of representing the community. However, this does suggest that barely faded comments are, themselves, more noise than signal. Also, more obvious examples of incorrect downvotes, i've found, tend to be corrected over time.

Also, there is a subset of downvotes which were meant to be upvotes but they just fat-fingered the wrong button.

There is also a principle at work behind several design aspects of the site, intended to stave off the "Eternal September" syndrome. Fading out unpopular comments, whatever the reason may be for that unpopularity, may be a way of discouraging participation of any kind with threads which could even remotely be considered of 'low quality'.</comment>


How One Man Waged War Against Gravity - <AUTHOR> http://www.popsci.com/science/article/2011-03/gravitys-sworn-enemy-roger-babson-and-gravity-research-foundation

<comment><USER2> Stephen Hawking is not a Nobel laureate.</comment>


Technical deep dive on the iPhone X - <AUTHOR> https://techspecs.blog/blog/2017/9/13/thoughts-on-the-iphone-x <comment><USER2> I'm most curious to know what's going on inside that neural engine.

<comment><AUTHOR> Probably an ASIC with int8 and lots of SIMD? Beyond that, ¯\\_(ツ)_/¯</comment></comment>


Weebly, A YC company, closes a $650k Investment - <AUTHOR> http://www.techcrunch.com/2007/05/09/weebly-launches-blog-platform-bags-650k-investment/ <comment><USER2> Apparently Weebly took YC financing after being featured on TC. I am pretty sure this creates a different mentality from the investor perspective, YC included.

If YC finances a rising company, as opposed to paper-idea company, they have a much better look at how the market is reacting; would it be fair to say that in this way, it is much easier to spot potential successes, and fund very much in the style of a normal VC, as opposed to early stage seed funding?

I would assume so. And if that's true, is it fair to say the Weebly would've done equally well without YC funding, and directly went for larger investments? Or was YC the stepping stone for that? And if so, how?

<comment><USER3> we would not have been able to raise if it wasn't for yc, and several of the yc alums that helped us along

</comment></comment><comment><USER4> I just created a blog for my upcoming web site!

They've REALLY improved since the last time I looked. I thought back in March that they really needed to have a blog, and they have it! Here's my site:

ratemyapp.weebly.com

</comment><comment><USER5> What Weebly Could Do: Make their editor a drop-in / turn-key service for other sites to use as their Custom Profile Editor for users's profile pages.

Co-brand that biatch and call it a day.

</comment><comment><USER6> Is this like Infogami 2.0?

<comment><USER5> Perhaps Viaweb 2.0

</comment></comment><comment><USER7> Congrats to the Weeblys. I used Weebly for the first time about a week ago when I wanted to quickly put a page of info. It works well.

</comment><comment><USER8> Is that considered angel, or VC money?

<comment><AUTHOR> VC

<comment><USER3> you'd be surprised. the lawyers consider it a series a, but journalists consider it angel

</comment></comment></comment><comment><AUTHOR> One sure thing is that YC invests in companies that enables the average Joes (like me) to do things the simple way. It has to be dead simple to use (well I am sure there a few exceptions). I am not sure I would use Weebly, but it sure can help several people with little technical background. Does anyone knows if Weebly lets you use a custom URL?

<comment><USER9> Weebly lets you use a custom URL and you can download your site as a zip archive.

</comment></comment><comment><USER10> Seriously now, is this a business? Seems more like a project to me.

<comment><AUTHOR> It seems to me that Weebly has a long term strategy. They are trying to build a good user base. As they improve their service those non-technical users will learn how to build more complex websites and eventually some applications. It is sort of like starting a Kinder_garden with the goals of adding a Grade each year so your students won't have to look for another school.

<comment><USER9> That doesn't have anything to do with them making money. I don't think their monetization path is very important because best-in-breed web applications don't have a problem getting acquired.

If Weebly was a Web 1.0 company, the founders would be billionaires already.

<comment><USER11> "If Weebly was a Web 1.0 company, the founders would be billionaires already."

Poor logic.

<comment><USER10> Very poor logic. Logic doesn't prevail at Y-Combinator.</comment></comment></comment></comment></comment>