Comments URL: https://news.ycombinator.com/item?id=46546890

Points: 4

# Comments: 0

But these days, I do highly recommend Onshape -- it breaks down a lot of the 'rules' that I thought I knew about CAD software. I started using it about two months ago; one of my clients uses it for real industrial design of some IoT hardware, so it is powerful enough to do real things. Before I started using Onshape, I thought that 1) all CAD software was a million billion gigabytes, and required stupidly powerful hardware for no readily apparent reason, and 2) had an annoying licensing model that requires you to jump through hoops to get access to the free tier. Well, neither of these are true with Onshape: I went from 'hmm, maybe I should try this for my personal projects' to 'constraining a sketch' in about 90 seconds ... on Linux ... in Firefox ... on my Shenzhen ThinkPad ... with an Intel GPU. I was blown away at how much it failed to suck.

Anyway, my suggestion on choosing software is: it probably doesn't all that much matter. What you want to learn is the CAD mindset, not the software. An experienced MechE once told me that if you are not careful, you can end up writing 'spaghetti CAD'. These tools these days give you a lot of features that are, in theory, more expressive, but in practice, can result in unmanufacturable parts or unmaintainable designs: be careful!

And yes, the ELEMNT is an ok cycling computer, but I think with a few bug fixes, it would work 'at least tolerably' for hiking (that is to say, at least as well as the Garmin Edge 510 did). The Edge 510 was not a great hiking computer, but for 'datalogging with a separate battery from my phone, and capable of speaking ANT+ to my heart rate monitor', it at least captured correct data...

But also, the other side of this is that the attribution issue is, perhaps, only 50% of my thrust here -- the other 50% being that it's actually a really cool device inside, and it's neat to see how they managed to build a device that's (mostly) competitive with Garmin's rich feature set so quickly. And so that, I think, might be what would be even more interesting to HN, rather than just torching them. If they opened the platform up to tinkerers a little bit -- perhaps if they 1) unlocked the bootloader; 2) provided /system images; and 3) enabled a switch to give you access to adb -- then it would be a really really cool form factor of a toy for a lot of different uses.

In the early days of compilers, of course, you were mostly writing C as a macro language for your system's assembly language. If you wanted your program to perform well, you'd have to write C that was, more or less, a translation of assembly that you'd constructed in your head first. If you wrote bizarre C, you'd either get incorrect results, or if you were lucky, you'd get correct but inefficient results.

But that's also Dan's point: Verilog isn't a "high level language". You don't write programs with it, you describe hardware with it. (In fact, that is why it is called a 'hardware description language'!) So if you try to write a program, instead of describing hardware, you'll get something that isn't really either.

Comments URL: https://news.ycombinator.com/item?id=12857278

Points: 6

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=12850227

Points: 198

# Comments: 23

It's still not a perfect solution. I give up a lot privacy that way, and in order to use Contributor, I have to give up some of the other uBlock features that I really like (in particular, element-based blocking).

I will note, though, that I don't feel in the slightest bad viewing Facebook or Twitter with ads blocked. Facebook and Twitter survive by network effects; I couldn't reasonably opt out of using their services even if I want to. Since I'm forced to use their services, then, I think it's reasonable that I do so on my own terms.

I started blocking ads because they dramatically slowed down my browsing experience. But I keep blocking ads because, fundamentally, I believe that advertisements are neurotoxins, and nobody has the right to poison me.

The old Sean Tejaratchi quote - popularized by Banksy - applies here, I think - http://www.readingfrenzy.com/ledger/2012/03/taking_the_piss

When I joined the company, the very first role I was put in was on the core bringup team for a complex ASIC -- that is to say, the team responsible for screening chips, and working on issues that affect all of the individual functional blocks. I joined about a month or two before silicon was to come back. So, I spent the first six or eight months or so at the company in the lab; the first month was spent familiarizing myself with the tools and boards that we'd be using, and then once silicon came back, I spent a bunch of long nights and weekends in the lab getting chips to various teams, and, in general, solving whatever system-wide problems showed up. Bringup was a lot of work but it was also a really good view into "how the sausage was made", so to speak.

After bringup, I moved to an IP team [1], where my title was "ASIC Engineer". At the phase in the project that we were in, most of the RTL [2] had already been written, and owners for each sub-block had already been assigned. So my job was to do a bunch of the "checklist" items for netlist quality. For instance, I spent a while reviewing test coverage, and waiving coverage for things that couldn't possibly ever be reached. Or I reviewed tool output that did "clock domain crossing verification" -- basically, the tool pattern-matched on various chunks of code to make sure that they were safe. And yes, I spent some time staring at waveforms, trying to debug our testbench, or any kinds of such things.

I spent a while on another couple bringups, which I volunteered for this time. I enjoyed them, and then gave myself some time off for each to compensate myself for my nights and weekends.

At some point, someone decided that I was a better architect than engineer, which is probably for the better, because I was very slow at checklist items. So at some point I switched to an architect role, which meant that I was responsible for doing the definitions of sub-units, rather than implementing the hardware for them or implementing the testbenches for them. And, in general, the whole specification process is part of the architecture team's job. So, one day, when there was an output quality problem with our block -- it worked as specified, but given that it did some image processing, the image quality had some defect, so the specification was wrong -- I was tasked with spending a few weeks to reproduce it on hardware, find register settings that made it better or worse, and finally, understand what the defect was in the specification, and how to avoid it in the future.

Another task I had as an architect was to do the definition for a sub-unit from the ground up. This was a year or two of work. My primary output, interestingly, was not code, but instead a 100-or-so page Word document that specified how the block was to work, and what registers should program it; the consumers of that document would be the hardware team that implemented it, and the software team that would build the software. And, subsequently, I was tasked with implementing a model of that block in C, which could be checked against the RTL that the design team wrote. Near the end of that project, I wrote validation tests for it, and yes, I then spent some time staring at waveforms helping the design team to understand why their RTL implementation diverged from my C model. (They were, often, right. I am very lucky to work with an extremely skilled RTL team.)

These days, I'm doing more algorithmic research, trying to figure out what should be next for the block that I'm working on. In parallel, I sometimes get on phone calls with, for instance, image sensor vendors, understanding on an electrical level what's going on inside of their next sensors, and how they will be transmitting data back to our processor. So even though I work in the digital domain a lot of the time, having a firm grounding in 'is it possible to wire this to this' has gone a long way to help out, and being handy with a soldering iron has made my life a lot better on more than one occasion.

My experience spans some gamut, but not all of it. I don't work on place-and-route, and I don't work on board design (at work, at least). There are a lot of things that electrical engineers do :-)

Hope this helps. (I can answer questions, I suppose, if you like.)

[1] For some reason, the semiconductor industry calls functional blocks IPs -- yes, as in 'intellectual property'. This particular IP was not something that we licensed to anyone, or that we licensed from anyone; the only 'customer' of this IP was our own chip team.

[2] Again, another acronym whose expansion ("Register Transfer Level") is not super descriptive. Essentially, source code. Usually in Verilog, or an even higher level language. EEs seem to love Perl and Tcl, so most places I've worked have had Perl or Tcl preprocessors before their Verilog. Ugh.

That said, I don't agree with the advice of the original poster. Self-medicating, /especially/ when you're in the thick of depression, is dangerous; there really isn't a whole lot of data around with regards to either safety /or/ efficacy in patients with depression. It's important that you have a support system around you.

So the paragraph that's buried in the middle -- "discuss with whoever's relevant" -- I think is the crux of it. And beyond that, the most important thing is to begin. Talk to your primary care physician; if you don't trust them, talk to a close friend; find a referral to either a psychiatrist or a psychologist. There are forms of therapy these days that are grounded in evidence, and once you have a support system in place, you might well find that experimenting with pharmacological therapies that are outside the gamut of institutional medicine is something that you want to try.

But if you have pain every day, the most significant bit is that it doesn't have to be that way, and there are ways to treat it; and beyond that, there are tested ways, and it's probably worth going with those first, so that you have the highest probability of feeling better faster, with the lowest risk of feeling even worse or compounding your problems with other side effects.

The policy on that web page has two egregious issues.

1) It does not have any provisions for SPAM. I regularly get e-mail SPAM that has CloudFlare-protected links. That abuse page does not even apply. Effectively, CloudFlare offers spammers a 'pink contract'.

2) CloudFlare has a reputation for ignoring abuse, and that page effectively says nothing about whether abuse will be stopped; that page only offers to transmit the personal information of someone who reports abuse off to an abuser. This is not a theoretical; this has happened in the past, and the personal information of someone who reported a site that contained child pornography was then posted all over the net for its users to begin harassment with.

So if you find something abusive or malicious, your best bet really is not to report it. CloudFlare won't act, other than to put you at risk.

Perhaps the additional green resolution on X-Trans sensors can help avoid this some. But I'd be interested to see how well this ends up doing on trickier images...