foxhill

it's to indicate that the text quote is as-written (which may not necessarily be a _mistake_), and from the perspective of the BBC, "realize" isn't alternative, it's just wrong :)

if we could make racemic glucose (i.e. a 50:50 split of D/L-glucose), the battle would be done.

you'd expect to see this if we had a purely synthetic process for the creation of glucose in the lab. but, as far as i know, we only have other biological processes that produce glucose, and as such, only produce the one isomer.

miners will choose to exclude transactions from their blocks if the transaction fee included isn’t high enough.

the transaction fee isn’t some algorithmically determined value, it’s completely controlled by market forces (for better & worse).

there are plausible arguments for transaction fees greatly exceeding even the original coinbase amount, although ultimately what matters is the value of those fees in local currency, contrasted with the cost to mine the block containing them.

because i expect miners to not operate at a loss. they can address this by either turning off their miners (which is most likely to occur when coinbase dominates the block payment amount), or by charging more to process transactions.

so far, by-and-large, the proportion of block profit coming from transaction fees has increased, as expected: https://buybitcoinworldwide.com/stats/fees-percent-of-reward...

apologies, this is non-sense. this is what transaction fees are for. the gradual reduction in coinbase incentivizes miners to charge for transactions, and the desire for transaction completion incentivizes clients to pay for them.

the paper you linked hand-waves away this for some reason, either to suggest that interest in bitcoin is purely speculative (which to be fair would only be half-wrong), or ignoring that market forces put upward pressure on transaction fee cost.

i’m a long time cubendo user. i’ve tried to switch to ardour a couple of times (although perhaps lacking in sustained effort), but i can’t ever quite seem to get the same productivity in my workflows - e.g. multi-track slip editing for a whole drum track recording, sidechaining effects, and routing (a non-exhaustive list). this is most likely a time/experience issue, to be fair.

what tips would you give me for making ardour feel a bit more familiar? i understand that’s a very vague question, and a vague response would be justified :)

indeed, and i agree - what i'm saying is that even today, the rasterization of triangles is still 2D :) (and necessarily will always be! well, as long as we use 2D displays..)

i'd argue that 3d-accelerated graphics from that era is still true 3d acceleration. of course, back then the pipelines were mostly fixed - nothing like programable shaders - but you're passing in 3d-coordinates, generating some matrices to determine the MVP, passing in some textures, and getting most of that "heavy lifting" of getting the pixels on the screen from the API & card.

> they were basically very fast (for the time) 2D triangle renderers.

that's still true of GPUs today :) in fact, with the exception of h264/265 encode/decode, and "AI" - that's all that graphics cards have ever done!

i agree with a lot of this;

> I was not happy so see that my mouse felt laggy

i also noticed this immediately and it was infuriating. my display runs at 240hz, so there must be at least 2, maybe even 3 frames of latency for it to be noticeable. it's made more perplexing that wayland was supposed to represent a reduction in latency.

> Out of the box, there’s a bit of that in wayland too, but sway has a way out: max_render_time.

this is possibly the worst way you could reduce input latency - mostly because of the tail-end of render times will be the most noticeable and the worst performing - please never do this unless you're trying to make your users inexplicably angry :)

> when really, other X servers exist, and have varying degrees of support for the extensions Xorg supports

a non-point here from me but i only know of XOrg and Xfree86, and i think the last time i tried that, linux kernels started with a two.. :)

i really want to support Wayland. X has done us well, but it's about time a protocol based around more modern situations supplants it.

Wayland has a myriad of these sharp-edge cases which i also find each time i try it out. what worries me a little is that some of them are clearly design decisions with no simple remidiation, your crashing example (which i have also witnessed first hand) is one of them.

the noise floor at 16 bit is already low. 24 bit, much more common (and imo needless for consumers), is 256x lower than that.

there’s no part of the analogue capture process that can utilise such a low noise floor (as far as i’m aware): is there anything of value worth preserving there?

apologies, i’d read it in a more accusatory tone.

not really, human memory is surprisingly non-linear, and temporal ordering is pretty poor. even for important events.

more importantly, making someone aware of their inaccuracy of something so close to them could quite possibly make them feel ashamed, or embarrassed, perhaps even disrespectful. but it’s just how memory works.

it likely had a different console at the time, and changed to an xbox at a later date.

also perhaps it’s not worth nitpicking minutiae over someone’s account of a tragedy.

chromium people are chrome people. google provide chromium either as a literal requirement for compliance with some other open source licence, or as a vestige from the “don’t be evil” days.

apologies, i don’t understand. you seemed to suggest cars are a significant contributor to CO2 emission.

and automotive emissions account for ~10% of all CO2 emissions. 20% if you want to include all transport (e.g. sea shipping, planes, etc.)

there’s been a lot of media attention on how individuals need to make an effort to beat climate change, but the reality is that industry is the only sector able to make a meaningful impact.

it’s a more practical solution for right now though. we can’t expect the world to switch its entire infrastructure overnight, or even quickly. yes, the rich nations might get a head start, but they represent such a small fraction of emissions.

even if it ran on gasoline created from carbon dioxide extracted from the atmosphere?

most other aspects. not all.

it looks like that battery is exactly what i'd said it'd be: a flat, less space efficient form factor. all you're seeing here is fewer layer penetration from the puncture, and more surface area to dissipate the heat over.

note, you can't stack these on top of each other (without loss of safety), otherwise you have a conventional battery again, this time with more conductors in between each cell.

> To make a battery safer, you reduce the ways it can give up that energy.

well, not exactly:

> [...] some batteries will give up their energy if they are penetrated with a sharp object. Some won't.

and your options for surviving punctures are essentially either:

* make the battery store less energy, or

* don't stack/roll the battery layers.

the first is clearly a non-starter, the latter necessitates very flat & space wasting batteries.

> [...] Some tolerate high temperatures, some don't.

lithium based batteries chemistries are completely unfavorable to high temperatures. there is no way around this, without changing the chemistry of battery (which is likely an energy density decrease), or adding thermal mass to soak up extra heat for some finite duration.

> Energy density is only loosely correlated with safety.

ok, consider this scenario: say we found a battery chemistry is resilient to puncture. can tolerate hundreds of degrees of heat without issue, and can sustain the power required to drive an electric car. ultimately you have 50kwh battery with a positive and negative terminal. you could put a bar of copper over those terminals. one of two things is going to happen;

* the copper will rapidly heat up and explode

* the battery will rapidly heat up and its container will explode

this battery is still very dangerous.

i'd say about the same - less than 10 times a year. this isn't just about us as individuals; we still have buses, taxi's, rental cars, service cars, trucks, car-sharing, planes, etc.

few of these can viably use batteries (and when they can there's usually an additional consequence). not with out either a significant increase in energy density - which has its own risks - or another massive investment in things like rapid battery exchange.

great, your vehicle works for you. as i said, EVs have a significant role to play in our society. i don't want you to throw away your EV or have it taken from you.

all i'm saying is that i believe gasoline to be a better energy storage mechanism for a significant proportion of transportation needs.

> You seem to be under the common misconception that it's the energy density of batteries that make them unsafe.

not at all. in fact, i said their (comparatively) low energy density is what makes them safe. that low energy density is a problem for range, places a lower bound on the size of vehicle, and somehow fixing that issue will make battery storage a far less safe option.

> There's nothing inherent about battery energy density that makes them more dangerous.

yes, their absolutely is - gasoline requires air to burn. batteries store energy, and they can discharge that energy without any other materials: a battery could burn in space.

> What makes LiPo/Li-ion unsafe is that they have a flammable liquid electrolyte in the middle.

well its the combination of the electrolyte and the metals that make the battery the battery, it wouldn't be battery without it.

> EVs, even with LiPo/Li-ion, are FAR safer than ICE vehicles, there's just no competition.

indeed, and i don't disagree. i think you may have misunderstood what i was trying to say about about safety here: i'm not trying to suggest that gasoline vehicles are inherently safer, at all. i'm saying that if you were to create a battery technology that was even 10x more energy dense, i.e. 10MJ/kg, you'd have great difficulty in making that vehicle safe.

> But the fire department here in Norway say they already have the needed training/experience, and make it clear that EVs are far better for fire safety in general.

once the battery has started burning, it has basically inextinguishable. "clear the area" is the only option you'd have.

> As for your points on whether they're better for longer distance, personal journeys.. I mean, yeah.. at some point they are. If you're driving 1000km in a day I'd definitely agree. But how many people do that often?

in Europe? probably not much. in the US? India? Pakistan?

> [...] For most people the range of EVs is good enough, even for long trips.

likely true, and, as i mentioned, EVs have a place.

> Almost every single road-trip charging session for me has been: 1. spend 30 seconds plugging in and beeping the payment card (with Tesla you don't even have to do this). 2. walk into a restaurant/cafe/grocery store and take a pee, drink some coffee, buy groceries for the trip, etc.. 3. come back to a fully charged car

well there's a couple of issues there - adding 30/45 minutes to a journey like that might not be suitable for everyone. traumatic charge rates (above 4C) are not good for the battery, too.

> The only reason you need that expertise with ICE drivetrain is because it's so hard to maintain.

well even the linked video states that this isn't really the case these days for ICE vehicles, a point i largely agree with.

regardless, if gasoline could be recovered from the atmosphere - closing the CO2 cycle - what would be so bad about this? as it stands, with EVs alone, we're pushing the costs of a complete infrastructure change over to individuals. sure, government assistance might help us here in the west, but that's not the world a lot of people live in.

i honestly think gasoline is a far batter energy storage platform for longer distance, personal journeys.

* far higher energy density, ~45MJ/kg compared to LiPo's ~1MJ/kg. (in fact the latter is probably the only reason LiPo is safe at all - more on that)

* essentially immediate "recharge" time

* 100+ years of ICE drivetrain expertise

* LiPo is a "two-part"-like fuel - it has everything it needs to release the energy stored inside of it (as opposed to gasoline that requires an external supply of oxygen). improvements to energy density necessarily make it less safe: LiPo battery fires are very difficult to extinguish, and release most of their energy in a short period of time.

to be clear, EVs have a place, for example, congested and population dense areas, where the primary concern is air quality, rather than global CO2 emissions.

i really think consumerism/capatilism coupled with society's less than healthy relationship with science & futurism have made EVs seem a lot more attractive than they really are. i'm not so sure i'm comfortable with the conditions of the mines where the rare-earth metals required for all these battery packs comes from.

IMO, technologies that capture carbon from the air and produce gasoline are far more attractive. the energy for which should naturally come from the sun, even if this process is "inefficient" - we receive the energy regardless of whether we use it or not.

more broadly speaking, right-to-repair/user serviceability has been degraded for most consumer platforms. even modern gasoline cars face the same problems as EVs. work (likely legislation) needs to be done on every front to improve this, in all facets of technology.

eh honestly i don't think extensions are really all that bad. it's a standard and extensible way for third parties to advance the API, and - presuming the extension is rationalized into the API appropriately - allows for clean evolution & progression.

on the other hand, i'm not so sure that i agree with the approach of advertising even basic functionality (e.g. swapchain) through extensions. i understand vulkan has uses outside of graphics. i think that could have been better exposed with hard profile boundaries or something..

i was paraphrasing for someone who might not be familiar with graphics basics, let alone architectures of bindless/GPU-driven rendering pipelines :)

OpenGL 3 deprecated glBegin/glEnd, but there is still state, and a lot of it. none of the OpenGL API is re-entrant, for instance..

imo, it’s unlikely that it will get much easier directly. if you’re interested in getting into GPU programming, i’d still recommend it. i know it can be daunting at first - the API spec is huge, and there are lots of things to get your head around. ultimately though, the concepts are not exotic or hard to understand. it’s certainly no more difficult than learning to program a regular computer :)

OpenGL done us good for a long time. Khronos (the standards maintainer) refused to advance the standard in any meaningful way since the API was based around a stateful glBegin/glEnd model.

modern graphics hardware does not work well in this model. they’re really much closer to whole other systems. you want to push the triangle data into the card in a single (or few) API calls, then submit as few draw calls as you can manage.

fun fact, OpenGL 3, originally code named “longs peak”, was supposed to upend the stateful model, and advance the API ahead of its proprietary counter part(s) - DirectX. for what ever reason this completely fell apart, and OpenGL just sort of.. stopped improving :/

we have Vulkan now basically thanks to AMD opening their more modern GPU oriented Mantle API, and valve for running with it.

> USB is a well known standard and power saving in USB is also well understood and exercised. PCIe power saving was not even a thing until relatively recently

well i mean it's all PCIe at the end of the day - all the USB stacks run on top of PCIe lanes - principally anything USB is pure overhead.

> PCIe power saving was not even a thing until relatively recently, and anything you'd developed for this new "HCI-over-raw-PCIe" thing would have to be done almost from scratch.

as far as i can tell PCIe power saving is still not a thing (at least of any significance). in any case, the energy usage of the transport layer and what messages you're sending over it should be largely orthogonal - i don't know exactly what you think you'd need to implement here. i mean, we're not being hypothetical here: apple have literally done this in their new macs, and the blog post specifies what they had to do to make it work in asahi: send the bluetooth HCI messages over the PCIe transport directly!

> [...] and may even provide further physical power saving considering how dead simple USB is as an interface

again, it's all already on PCIe no matter which way you cut it..