447 karma · joined July 5, 2019
All comments are strictly my own opinion and do not in any way reflect the opinions or views of my past or present employers.
If the Model M or F are appealing to you, at this price point you should also consider some more modern production keyboards or even building your own from a kit + switches + keycaps. If you're after the heavy & tactile keypresses of buckling springs a board with Cherry MX Clear (common) or Green (less common) will probably satisfy you - I can highly recommend any of Leopold's boards with Clears in them.
The key phrases are "imposition of direct military control of normal civil functions" and "suspension of civil law by a government".
The Canadian Emergencies Act, which was invoked by the Liberal government today, specifically states the following: "For greater certainty, nothing in this Act derogates from the authority of the Government of Canada to deal with emergencies on any property, territory or area in respect of which the Parliament of Canada has jurisdiction" [2].
I'd do a deeper reading but I'm a bit lazy, but my understanding is that the EA does not allow, in any way, a shift in governance that could be described as "martial law" - where the military is in control of civil functions and can create or remove laws as military leadership desires. Even with the EA invoked, the federal government still controls the Canadian military (but can be assisted in enforcing civil law _by_ the military).
I'm no fan of Trudeau either, but we should seek to be precise when discussing hot situations like this. People can get very inflamed off of internet posts and the idea that we're under "martial law" is riling people up.
[1] https://en.wikipedia.org/wiki/Martial_law
[2] https://laws-lois.justice.gc.ca/eng/acts/e-4.5/page-1.html
Broadly speaking, FPGA-based ML model accelerators are in an interesting space right now, where they aren't particularly compelling from a performance (or perf / Watt, perf / $, etc.) perspective. If you just need performance, then a GPU or ASIC-based accelerator will serve you better - the GPU will be easier to program, and ASIC-based accelerators from the various startups are performing pretty well. Where an FPGA accelerator makes a lot of sense is if you otherwise need an FPGA anyways, or the other benefits of FPGAs (e.g. lots of easily-controlled IO) - but then you're just back to square 1 of "there's some cases where an FPGA makes sense and many where it doesn't". Besides that, a few niche cases where a mid-range FPGA might beat a mid-range GPU on perf / Watt or whatever metric is important for you.
Again, opinions are my own and all that. As someone in the space, I am very much hoping that someone - whether an ASIC startup or Xilinx / Intel come up with a "better" (performant, cheaper, easier to use, etc.) solution than GPUs for ML applications. If the winner ends up being FPGAs, that would be really really cool! Just at the moment it's not too compelling, and I'm trying to be realistic.
All that said, FPGAs and their related supports (software, boards, etc.) are an $Xb / Y market - nothing to shake a stick at, and there are many cases where an FPGA makes sense. Just doesn't currently make sense for every dev to buy an FPGA card to drop in their desktop to play with.
Nobody has come up with a good answer yet. Developing for an FPGA still requires domain-specific knowledge, and because place & route (the "compile" for an FPGA) is a couple of intertwined NP-hard problems development cycles are necessarily long. Small designs might take an hour to compile, the largest designs deployed these days ~24H.
All this to say is that while they are neat, nobody has found the magic bullet use case that will make everyone want one enough to put up with the pain of developing for them (a la machine learning for GPUs). Simultaneously, nobody has found the magic bullet to make developing for them any easier, whether by reducing the knowledge required or improving the tooling.
Effort has been made in places like High-Level Synthesis (HLS, compiling C/C++ code down to an FPGA), open-source tooling, and (everyone's favorite) simulation, but they all still kinda suck compared to developing software, or even the ecosystem that exists around GPUs these days. You'll often hear FPGA people saying stuff like "just simulate your design during development, compiling to hardware is just a last step to check everything works" - but simulation still takes a long time (large designs can take hours) and tracking down a bug in waveforms is akin to Neo learning to see the Matrix.
Never seen a shop do ageing, so the wine will be noticeably "young". My parents like dryer and sharper white wines anyways (Pinot Grigio, Riesling, etc.) so it doesn't bother them. Also note that due to taxes and such, the cheapest wine you'll find commercially is C$11 a bottle, so even at C$20 / gallon you're getting a great deal if you like the resulting wines.
Personally, I quite like the wines my folks get through these shops - properly chilled they make a wonderfully refreshing beverage in the summer, and we'll often drink a few bottles on the back deck together when I go to see them.
Thanks for the information though, I'll do some A/B testing to see if it makes any difference to me.
I think the 70s are also around the same time that a lot of familiar genres started to emerge, while music from before then is often dismissed as "oldies" or saved for special occasions - e.g. old crunchy recordings of Christmas songs.
That's interesting, can you expand on this? I'm curious what could have impacted them that much (I'm a student about to finish my undergrad in comp eng)
Making a device at a specific technology node (e.g. 14nm, 10nm, 7nm) isn't just about the lithography, although litho is crucial too. In effect, lithography is what allows you to "draw" patterns onto a wafer, but then you still need to do various things to that patterned wafer (deposition, etching, polishing, cleaning, etc.). Going from "we have litho machines capable of X nm spacing" to "we can manufacture a CPU on this node at scale with good yield" requires a huge amount of low-level design to figure out transistor sizings, spacings, and then how to actually manufacture the designed transistors and gates using the steps listed above.
In the days and weeks following I felt amazing, with almost all of the post-breakup blues gone and a fantastic outlook on life - I chalked it up to the "near-death" experience, but later found out about the potential anti-depressive properties of the drug and I've wondered ever since.
I find your description here fascinating, because it's exactly how I've described the CityPlace district [1] here in Toronto that was built over the last 20 years, with most development in the last 10. Makes me wonder how common this style of modern, sterile, "ideal" development is in big cities around the world.
[1] https://en.wikipedia.org/wiki/CityPlace,_Toronto
(I also think it's interesting how both HafenCity and CityPlace work the word "city" into their title, with a similar naming scheme)
Not sure if they're quite at the same level (hard to measure apples against apples and all that), but there's a few companies in the space - namely, Groq, Cerebras, Tenstorrent, and Untether. Besides that, both major FPGA vendors have ML inference IP available.
I'd also bet other FAANG-ish companies are trying, besides just Google, but I would expect anything to come out of them to also be compute-as-a-service like Google's hardware.
I think what they mean is that when you're defining synchronous logic in (System)Verilog or VHDL, the behaviour of that synchronous logic is defined as being in response to an event. For example, look through a Verilog codebase and you'll probably see lots of blocks that look like the following:
always @(posedge clock) begin
... // Some logic
end
What that block says is that the logic defined inside it - most often writing to some sort of storage element, or sampling a signal - will trigger at every positive edge of the "clock" signal, which is the "event". Usually, people will work in more control signals like a clock enable, reset, etc. to make it do more interesting things.That's exactly what I was trying to point out. Animal product industries have so many different ways in which they're cruel to animals - e.g., for dairy, the things I pointed out that are missing from the posted webpage - that individual companies can try to make themselves look better/ethical by pointing out the one or two things they're doing better than average, while omitting all of the other horrific parts of the pipeline (as another poster in this thread said, "ethics-washing").
What I found interesting while reading this was what it _didn't_ say. Specifically, they mention that calves are kept with their mothers for 5-6 months, but what happens to them after that? They also don't say how long they keep the cows themselves for.
Typically male calves are sent for slaughter [1], and females raised to be dairy cows themselves. Furthermore, dairy cows are usually slaughtered after only 5 years of life [2], while the natural lifespan of a dairy cow is ~20 years [3].
[1] http://ontarioveal.on.ca/all-about-veal/the-real-deal-about-...
[2] https://albertamilk.com/ask-dairy-farmer/how-long-does-the-a...
[3] https://animaldiversity.org/site/accounts/information/Bos_ta...
Though, you do need to carry it in a case of some sort, because the tip doesn't retract.
The "XOR trick" actually nearly sank me on an interview once, I'm assuming because the interviewer shared your opinion. One of the questions they asked me to solve was the "n - 1 numbers in a list" question the article talks about - I promptly came up with the XOR solution because I have more background in low-level work than the high-level finance role I was interviewing for. Turns out, they had never seen it before, didn't really understand how/why it worked, and they took a lot of convincing to accept it as correct.
I think I only still got the job was by then proceeding to also solve the problem the "normal" way.
So, your statement is true because you say that it's common knowledge that it's true?
> Primary and secondary production, is a big fat chapter in any Ecology handbook
OK, then kindly provide one of these ecology handbooks that proves your point
> If nobody is trying to produce a natural sized cow sculpture made of vanille beans, there must be a reason
What do you even mean by this?
This is a cherry picked argument, at least in the US, where "factory farms raise 99.9 percent of chickens for meat, 97 percent of laying hens, 99 percent of turkeys, 95 percent of pigs, and 78 percent of cattle" [1].
Besides, even in this ideal farm where the farmer treats the animals perfectly and lets them live long, fulfilling lives, they're still killing the animal at the end of the day. Hard to see how that is "treating [it] well".
[1] https://www.huffpost.com/entry/its-time-to-end-factory-f_b_1...
I've noticed in tech that a common hope that people in tech hold is that "the billionaires", in their infinite wisdom and generosity, will pull magical solutions out of their hats and save us all. Like you mention later, yeah, right.
> one of the thousand reasons I got out of tech
Not an option I've considered much, but it's almost tempting.
[Citation needed]
I'll assume you're arguing in good faith, but this argument is a common straw man made by people who are against plant-based diets. In fact, the only case where you have a point is that the worst case for chocolate produces more emissions than the best case for beef [1]. Odds are that if you're eating beef in North America it comes from a factory farm [2], while people who advocate for plant-based diets are often for more sustainable farming practices too, and will try to buy chocolate/coffee/avocados/whatever in sustainable ways.
Finally, the most important point is that it's not an either/or proposition - you can be _both_ for eating less meat, and producing plant products in more sustainable ways.
[1] https://www.bbc.com/news/science-environment-46459714
[2] https://www.huffpost.com/entry/its-time-to-end-factory-f_b_1...
Dance with the devil you know and all that.