In several US states, this would be outright illegal. While they're aimed at electronic communications, most two-party consent states require explicit consent from those present, and in some, the "but there was an obvious recording device" exception is restricted to journalists.
Yeah that too. Mostly I want perfect recall of the things I want to remember, but constraints like this introduce so much overhead into managing when it's turned on that it obviates the usefulness the rest of the time.
I’m not sure what to do except encourage others to consider, in the wake of the Snowden revelations and everything else, whether you really want Google to have all your email. And half of mine.
Looks like this article and the one you're replying to are in agreement.
Severe heat, heavy snow, or torrential rain can make driving a car unsafe as well. Individuals with certain disabilities, chronic health conditions, or a plethora of age may also find driving impossible. For those with "trip-chaining" needs, extra time required for parking cars can be prohibitive. Old people don't like traffic and can escape and run away so fast you have to drive them back? And you're seriously including the idea that car theft is not a concern? These are some tortured arguments.
The correct argument here is "if bicycles become the dominant transportation mode, then the government will absolutely mandate kill switches for them too." "Bicycles don't have software" hasn't been true for years. E-bikes and wireless deraillers have been around a long time.
Bikes without software will be around for the foreseeable future. They're the cheapest and most plentiful version of bike. In the unlikely scenario that all bikes somehow become electric, old bikes are much easier to maintain than old cars.
My argument to my own post is that cameras that track cars and license plates could easily be reconfigured to track bikes and pedestrians. In that case there's no transportation mode that will save you from surveillance. The cameras have to go.
You do get the idea though, that just because bikes work for what you need to do, they won't necessarily work for what any other given person needs to do, right?
Also, why the hell have you got wireless derailleurs? What is the point? What possible advantage can they have over perfectly normal mechanical ones?
brotli is ubiquitous because Google recommends it. While Deflate definitely sucks and is old, Google ships brotli in Chrome, and since Chrome is the de facto default platform nowadays, I'd imagine it was chosen because it was the lowest-effort lift.
Nevertheless, I expect this to be JBIG2 all over again: almost nobody will use this because we've got decades of devices and software in the wild that can't, and 20% filesize savings is pointless if your destination can't read the damn thing.
Congrats on solving philosophy, I guess. Since the actual product is not grounded in objective truth, it seems pointless to rigorously construct an ethical framework from first principles to govern it. In fact, the document is meaningless noise in general, and "good values" are always going to be whatever Anthropic's team thinks they are.
Nevertheless, I think you're reading their PR release the way they hoped people would, so I'm betting they'd still call your rejection of it a win.
The document reflects the system prompt which directs the behavior of the product, so no, it's not pointless to debate the merits of the philosophy which underpins it's ethical framework.
After reading that document twice, I'm still not sure why they based it on Illumos. I strongly suspect it's just down to the personal preference of the founders, which is a perfectly valid reason. This document very much reads like "here are the pieces we will use, let's work our way back to why"
The reasoning can be simplified to two things.
1. Linux does not have the bhyve hypervisor ported
2. Maintaining a Linux distribution will require more effort and have more churn than illumos.
Because Linux is just a kernel and users have to provide all of their own user space and system services there is a lot of opportunity for churn. Illumos is a traditional operating system that goes from the kernel to the systemd layer. Illumos is also very stable at this point so most of the churn is managed up front
The choice is between porting a handful of apps to illumos or jumping on to the Debian treadmill while pioneering a new to Linux hypervisor. Would Linux have enabled a faster development cycle or just a easier MVP?
There's no churn in a graveyard, either. Debian's not much of a treadmill on stable; it's famous for it.
The justifications for bhyve over kvm are similarly inscrutable; you can simply not build the code you don't want. Nobody's forcing you to use shadow paging. Comments like "reportedly iffy on AMD" are bizarre. What does "iffy" mean? This wasn't worth testing? Why should I, a potential customer, believe that these people are better at this than the established companies who have been producing nearly-identical products for twenty years? At the domain of development they're discussing why bother using an x86_64 processor from a manufacturer who does not bother to push code into the kernel you've chosen?
Again, it's their company, and if they (as I suspect) chose these tools because they're familiar, that's a totally supportable position. I just can't understand why we get handwaving and assurances instead of any meat.
You may disagree with our rationale, but it is absolutely absurd to complain that that RFD 26[0] does not have "any meat." This is in fact dense technical content (10,000+ words!), for which I would expect a thorough read to take on the order of an hour. Not that I think you read it thoroughly: you skimmed to parts, perhaps -- but certainly glossed over aspects that are assuredly not your domain of expertise (or, to be fair, of interest to you): postmortem debuggability, service management, fault management, etc. These things don't matter to you, but they matter to us quite a bit -- and they are absolutely meaty topics.
Now, in your defense, an update on RFD 26 is likely merited: the document itself is five years old, and in the interim we built the whole thing, shipped to customers, are supporting it, etc. In short, we have learned a lot and it merits elucidating it. Of course, given the non-attention you gave to the document, it's unlikely you would read any update either, so let me give you the tl;dr: in addition to the motivation outlined in RFD 26, there are quite a few reasons -- meaty ones! -- that we didn't anticipate that give us even greater resolve in the decision that we made.
I did indeed read your document (twice, as I explicitly reported). I didn't address those parts because I found them better-supported. Instead, I addressed the parts I found confusing, and since your rebuttal here is just whining about what you think my behavior is, I continue to be mystified. That's okay; nobody expects you to explain yourself to me. If I thought it would help, I would suggest that perhaps a more effective defense would involve answering literally any of the questions I already asked. However, I don't appreciate accusations of bad faith based on your unwarranted assumptions about what I did or did not do and, bizarrely, what you imagine my motivations are. I'll just assume that the answers to the "why" questions I asked are rooted in similar wild-ass speculation.
There is a reasonable explanation for the "foregone conclusion" flavour of the RFD that doesn't cast aspersions (quite as much as you are) on the authors:
It is simultaneously an assertion of the culturally determined preferences of a group of people steeped in Sun Microsystems engineering culture (and Joyent trauma?), and a clinical assessment of the technology. The key is that technology options are evaluated against values of that culture (hence the outcome seems predictable).
For example, if you value safety over performance, you'll prioritise the safety of the DTrace interpreter over "performance at all costs" JIT of eBPF. This and many other value judgements form the "meat" of the document.
The ultimate judge is the market. Does open firmware written in Rust result in higher CSAT? This is one of the many bets Oxide is making.
Frankly, I don't think Oxide would capture so much interest among technical folks if it was just the combination of bcantrill fandom + radically open engineering. The constant stream of non-conformist/NIH technology bets is why everyone is gripping their popcorn. I get to shout "Ooooooh, nooo! Tofino is a mistake!" into my podcast app, while I'm feeding the dog, and that makes my life just a little bit richer.
i'm not sure if Dtrace interpreter was safer than EBPF. I guess in theory it should be because a JIT is just extra surface area but I'm not sure in practice. Both EBPF and DTrace had bugs. Also, I always thought EBPF JIT was just a translation to machine code and it didn't do any kind of optimization pass so should be very similar to how DTrace works. They both ship byte code to the kernel. But I guess the big difference is EBPF relies more on a verification pass while I think most of DTrace safety verification was performed while executing the bytecode. I remember there was a lot of stuff in EBPF where the verifier was meant to be able statically determine you were only accessing memory you were able to. I think there was a lot of bugs around this because the verifier would assume slightly different behaviour than what the runtime was producing. But this is also not necessarily a JIT problem you could have an interpreter that relied on a static safety pass as well.
...but your top post didn't ask any questions; certainly not ones that would justify a detailed answer.
It was several assertions, plus your admission of confusion. I mean, there are no stupid questions, but there wasn't even a question there, so I don't blame anyone for thinking you're communicating poorly.
I wasn't accused of communicating poorly. I was accused of lying about reading a text file and having some kind of ulterior motive for my own opinions.
Furthermore, advanced readers are generally able to infer from "I am not sure why x" that a similar flow of discussion might be as feasible as if it were phrased "why x?".
As though that were necessary. There's plenty of room in this comment box for questions better fleshed out than "why x?". Are you expecting advanced readers, or clairvoyant ones?
Technical analysis is the projection of future price data through analysis of past price data (usually for the purpose of trying to create trendlines or find "patterns"). Options pricing is quite a different beast - it encodes marketwide uncertainty about the future price of the underlying, which has little to do with the past price action of the underlying, and everything to do with all known information about the actual underlying company, including fundamentals analysis, market sentiment, future expectations and risks, etc.
To put it another way, to price an option I need a) the current price of the underlying, b) the time until option expiry, c) the strike price of the option, and d) the collective expectation of how much the underlying's price will vary over the period between now and expiry. This last piece is "volatility", and is the only piece that can't be empirically measured; instead, through price discovery on a sufficiently liquid contract, we can reparameterize the formula to empirically derive the volatility expectation which satisfies that current price (or "implied volatility"). Due to the efficient market hypothesis, we can generally treat this as a best-effort proxy for all public information about the underlying. None of this calculation requires any measurement or analysis of the underlying's past price action, patterns, etc. The options price will necessarily include TA traders' sentiments about the underlying based on their TA (or whatever else), just as it will include fundamentals traders' sentiments (and, if you're quick and savvy enough, insiders' advance knowledge!) The price fundamentally reflects market sentiment about the future, not some projection of trends from the past.
This is a breathtakingly disingenuous summary of the article. I cannot imagine a perspective sufficiently warped to produce this interpretation a priori.
Agreed. It’s easy to imagine billions of reasons why people will people will defend indefensible behavior by companies with billions of dollars though.
https://gitlab.xfce.org/xfce/xfwm4/-/blob/master/settings-di...
reply