At least in my discipline, authors either retain copyright to their manuscript and can disseminate that freely, or they are able to personally disseminate the final published article (sometimes including on their own website). No copyright transgression occurs in this case.
One guidance for the ethical side are the guidelines agreed upon by professional associations. I can't think of any that condone copyright infringement.
So why not email the corresponding author? I have yet to not get (or give) a manuscript that way. From my own perspective, each time I respond I'm possibly getting another citation. It's also a great form of networking.
If they want to seriously engage regulated industries like finance, medical, energy, etc., they need to. As it stands now, an association with them is suspect.
Silicon Valley and YC don't exactly have a stellar reputation for ethical behavior. Having a "pirate website" at the top of the news page doesn't exactly change that perception.
I totally get that journals are evil, and charging money for research generated with public funds is questionable. It's very frustrating as a small entity needing to view articles, and being asked to cough up $25-50. That said, there are legitimate alternatives (like emailing the corresponding author, or professional society memberships, or alumni library access, or DeepDyve). The linked website is flagrantly violating copyright and that should be cause for concern; not breaking the law is part of every engineering (and professional) ethical code.
I find this is generally a poor place for hardware-related startups.
Places to check (and network with)—I'd try checking in with your university's tech transfer office: they might be able and willing to clue you into recently-formed startups licensing university IP. Another would be your university's professional practice office (may go by another name), i.e., the office that sets up student internships. Another is with your department's industry relations rep (if you have one). A fourth place would be in any hacker spaces or tech villages in town. A fifth would be with the local angel investor groups.
A really great possibility is to take your senior design project seriously. It's not unheard of for those to turn into something commercially viable.
I'm not a big FTIR person, but at least for Raman, laser power is far less important than the linewidth (and you definitely don't need a pulsed laser) and the rest of the optical engine. I'm actually pretty bearish across the board on these consumer spectroscopy products mostly due to the importance of sample prep. Your use case statement is correct, distinguishing paracetamol from candy should be easy, but is really that a common need or a novelty? It seems to be the latter to me.
If you consider it functional, Common Lisp is still used by some very large and established companies: the Lisp HUG mailing list (LispWorks) will frequently have email signatures from some of them. There is some truth to the notion that CL is a competitive advantage and so its use tends not to be discussed in the open.
The right way to do that would be with FTIR or Raman spectroscopy, and this sensor is capable of neither.
At best, this is an ersatz replacement for the tunable filter on a hyperspectral imaging system. There are some advantages (off hand, acquisition rate is a big one) to a more diverse mosaic filter, but other than in using QDs as the actual filter medium, this idea is not at all new.
I agree, the choice of programming language is one of the less important parts of the SDLC. In the case of Rust for SC work, as the linked article alludes to, what doesn't make sense to me is that there is no industrial-grade tooling or support software. It seems like an ill-informed statement.
As to proofs, I thought some level of formal proof was required at SIL4?
I go by what I thought was the accepted definition, which is a failure or error presenting a risk for temporary or permanent harm to people. Financial risk like data loss would fall under mission critical.
> Rust’s strengths are Clojure’s weaknesses, and vice-versa. Rust isn’t as expressive or interoperable, and its concurrency story isn’t as complete. That said, it’s much better for performance or safety critical needs, and it can be embedded inside other programs or on very limited hardware.
I find this hard to believe. Is anyone actually using Rust for a safety-critical application?
At night, I have to use level 7 on the backlight for comfortable reading without any other lights on. It's noticeably blue to my eyes at that setting. I get that Amazon's trying to make the display look whiter in normal light, but I (and I think others may) place more value on a warmer backlight for nighttime reading. Outside of vacations and doctor appointments, bedtime reading is my most frequent use case.
I upgraded from a Paperwhite 1 to a Voyage because I thought the screen and haptic buttons would be improvements. I can barely see a difference in the screen quality when I'm deliberately looking (and don't notice any while reading), and the haptic buttons are poorly placed so I rarely use them. The Voyage is nice but was questionably worth the extra money over the Paperwhite 1. Now with the Paperwhite 3? Fuggetaboutit.
You know what feature would be a great improvement? A backlight without blue light, for reading at night without screwing up sleep cycles.