Detroit, as the capital of the auto industry, has far more parking than just about any other city I've ever been to. There are huge, multi-story garages right on the main thoroughfare downtown.
> Detroit was, or is, Motor City. Its center can pull off another automotive-related nickname: Parking Central. Fully one-third of downtown Detroit is dedicated to letting cars do what they’re not designed for: standing still.
That’s what I thought! But all of the five or so garages we tried cost $20-40 flat with no ticket machines or anything, and I wasn’t willing to download/fight with an app to walk around for an hour.
Next trip will be more planned for sure. I was impressed with the highways though. Definitely a motorists’ dream to get around the various suburbs.
Needing to download an app, and saying "you need to book in advance" are not the same thing.
Just because you didn't want to deal with it and didn't do research ahead of time doesn't mean "We couldn’t even park downtown". You didn't want to, and that's fine.
There’s a giant parking lot with 10,000 spaces and 2 are free. There is ‘no parking’ unless you want to drive around for 2 hours.
For enough money you could probably get a permit from the cops and a security detail and park wherever you wanted, like in a city park. There is still ‘no parking’ in parks.
Within parameters that apply in the majority of cities I’ve tried to park in, there was no parking. In future I’ll download the app, book a spot and bring my phone charger and then I’ll be able to access the parking.
Saying there's no parking and there's no free (as in money) parking are two very different things. Parking in the downtown of one of the ten largest metro areas in the US is going to cost money. That's just how it is.
I don’t mind paying. In Toronto I’ll pay $20 no problem to park right in the middle of the core in a garage. But I have options to use cash or card at a meter or machine without getting my phone out. I can pay for an hour or 2 or all day.
In Detroit the options were street parking (all full) or flat rate in a garage behind an app. I looked for a ticket machine and there were none. My bad for not doing research but still, I had a good day elsewhere in the metro, was just surprised by the inflexibility in the DT core.
It was the end of the day and I wanted to walk around and scout out stuff for next visit. If I spent all day there I’d happily pay the $20-40 but not for an hour walk, that’s silly when I can look at stuff in Windsor where my accommodation and free parking were.
An app is easier to maintain and enforce than meters, and I don't need to carry coins or go back to the meter to add time. I'm all for them but prefer a web interface with Google checkout, or text messenging with a card on file.
I've had a question that I haven't seen anyone else ask that you might be able to shed some light on: is there an internal battery to facilitate switching power sources without an instant loss of continuity?
Why do we need an accelerator when we know how fast the wheels are turning directly? The first derivative of wheel speed is almost always car acceleration. Is this to handle some edge cases like not turning the brake lights on when we're actually sliding on ice with the wheels locked? Seems unnecessary.
Why is it unnecessary? Isn't the primary goal of brake lights to inform people of deceleration and the secondary goal to indicate when a vehicle is locked stationary?
Showing a speeding vehicle behind you that you've lost control and should slow down is well within the conops of brake lights.
I believe the poster is asking why do we need another sensor to achieve that goal? We already have a speedometer based on wheel motion. A trivial computation gives acceleration.
Because tires can block, not all tire turn at the same speed all the time, because redundancy is a good thing... There a lot of reasons. And if the number of sensors in your car bother you, well, the early 80s, with carbs and without ABS, are last model years you can buy.
Redundancy is a good thing. Do we feel manufacturers are cross-checking accelerometer with the speedometer? If not, there is no redundancy gained.
On the other hand, if your speedometer is faulty, or not working, you'll know pretty fast. If your dedicated accelerometer is faulty, you might have no idea what your brake lights are doing in the back.
Dunno; it just feels "we need to know acceleration, let's add an accelerometer" is a non-imaginative, add-cost, add-complexity idea. Again, if we think ABS and speedometer and the new accelerometer are being cross-checked and sanity-checked, awesome, but I'm just a bit cynical of that, compared to adding the 3rd thing to do the same thing.
No idea what Kubernetes are, and I am serious here, since I am no software dev. On the hardware side of things, there is redundancy and complexity. Those two might look similar on the surface, they are totally different beasts so.
To simplify it as much as possible, Kubernetes is a system that deploys and manages containers. Containers allow multiple programs to run under the same system while being completely isolated.
However, Kubernetes is actually incredibly complex. It's powerful, but holy hell does it add complexity. And yet it's basically a buzzword and people are using it in very basic scenarios that don't call for the complexity that Kubernetes adds.
So that's where my joke comes from. There are people that behave as if adding unnecessary complexity is a feature.
Many late 80s/very early 90s fuel injection vehicles have shockingly low numbers of electronic sensors also. MAP, O2, TPS, CPS is all you really need. Some of them are even analog.
What do you save by not having that sensor? Nothing. What do you lose by not having that sensor? The ability for the system to perform its requirements.
I'm assuming you read the context of loss of traction being a requirement.
A $9000 repair bill in 6 years when your mechanic tells you “Sorry your car is immobilized and won’t start, the deceleration brake light sensor went and we need to remove the motor and 3/4 of the wiring harness to replace it”. And for anyone who thinks I’m being sarcastic, try owning a BMW or an Audi and you’ll know it’s the truth.
A MEMS accelerometer is pennies. If it is critical then add redundancy and don't accept single fault tolerance. If it is optional or the signal can be estimated from other sources with acceptable error then fail gracefully. This is honestly simple stuff. Accepting less from manufacturers is a bad deal.
That's an dishonest argument (perhaps not intentionally). NOTHING is "pennies" to a consumer when it comes to repairing a vehicle. More frequently, you pay $1,500 in labour and parts to replace something that costs "pennies" in some bulk manufacturer wholesale catalogue.
Modern cars are getting more and more awesome, in terms of safety and convenience; but the sticker shock when going to dealership for repair is also becoming bigger and bigger, and it absolutely is intertwined with the significant effort to make 3rd party or even self-repair difficult to impossible.
So again, IFF this is an easily replaceable part that is thought-through and cross-checked intelligently with other existing sensors, brilliant. But can you at any level understand my skepticism that any of these are true? :)
I'm not talking about the price of maintenance but the cost of manufacture. Please give generous interpretations rather than ones that fit an argumentative narrative. Assuming the topic is cost of repair rather than manufacture makes no sense when we're talking about system engineering to accomplish functional requirements.
I have owned a troublesome 2010 BMW for 8 years now. No individual repair has been over $2,700.00. Most are closer to $1,500. I was quoted (by a dealer) $15,000.00 for engine repair once but it turned out to be a spark plug. $9,000.00 sounds like a dealer quote. Find a good independent shop.
Relatedly, having a dedicated accelerometer sensor is a baseline dependency of many of other modern features like cross-comparing compass headings and GPS for map heading information (much less any of the Level 2+ "self-driving" mechanics). Most cars likely want one, anyway, even in base models. It's one of the cheapest sensors in a suite of increasingly standard sensors (in almost any form factor of device, not just cars, but phones/watches/toasters/etc).
One more possible reason might be when driving down a hill: When descending a sufficiently steep incline, I may be braking just to maintain my speed! That said, I'm still _feeling_ negative acceleration to maintain a constant speed. (That said, if I'm doing this for more than a handful of seconds, I'll generally downshift, and _that_ doesn't trigger brake lights, despite also causing increased negative acceleration. So maybe regenerative braking is analagous, and fine without brake lights?)
> Why do we need an accelerator when we know how fast the wheels are turning directly?
Because the car doesn't precisely know the wheel's radius. The radius depends on the rim, tire, and tire pressure - and the car's operator may have accidentally or deliberately chosen something unexpected for any one of those 3 parameters.
You're not wrong but how much does not precisely knowing the wheel's radius change things?
The operator would also experience an incorrect speedometer. For the purposes of a brake light it'd be off (either lighting up too soon or too late) by some amount but I imagine it'd be "close enough" except for the most pathological cases of tire sizes.
You don't need to know the wheel radius, you just need to the rate of change of the wheels RPM. Then the brake light could be set to some conservative value where regardless of any realistic tire size/inflation scenario the brakes will activate at a reasonable deceleration.
In any case, with standard gas/brake pedals on ICEs, I can barely tap the brakes and have my brake lights turn on without any deceleration on my part, or I can do that and still be pressing the gas and so actually be accelerating with my brake lights on.
This is not a problem. We know this isn't a problem, because ABS almost always uses wheel speed sensors to do it's thing, and ESC usually taps into the same wheel speed sensors. Hell, those sensors are often used to tell you when your tires are low on pressure, and yet that doesn't prevent any of the other functions from working, or even affect your speedometer enough to care.
Changing wheel size enough to affect readings of speed does not change the broad slope of the derivative of wheel speed.
ABS relies on the fact that the computer knows how fast the wheels are turning in relation to each other. Wouldn't seem to be much of a leap to leverage that system to determine if the car is slowing down.
If the car doesn't know the size and speed of the tires it also can't accurately display the current speed, which seems like at least as pressing a problem.
Edit: Or is detecting deceleration more sensitive? I guess I don't know how precise it needs to be relative to how precise a speedometer needs to be.
I don’t think it’s such an edge case at all. I imagine it would be disconcerting to the driver behind you if you slammed on the brakes on a wet road, locked the wheels into a skid, and the brake lights went out. (Shouldn’t happen with modern braking systems, but still…)
Tesla is 65 on the Fortune 500, and Twitter was ~600 before the acquisition. SpaceX is also huge, but it's hard to say just how huge without it being public. The amount of commitment and work to become CEO at a company that's even 600 on the Fortune 1000 is insane. A quick google says there are 213 million companies in the world, I think having at least two in the top 1000 counts, no?
While that's certainly one way to synthesize directional audio, the far more common way is to actually have the audio come from the direction it's supposed to and let your ear do its normal thing to sort it out. Imagine you had an entire room wallpapered in individually addressable tiny speakers, you could actually project sound from any angle. The added benefit being that it would work for more than one person in the room. we've gone from 2.1 audio -> 5.1 -> 7.2 -> atmos 11.2. Why wouldn't we want to go to 50000.2 audio as the next extension?
Atmos is not 11.2!
Home theater Atmos is 12 statically positioned streams, usually 7.1.4 (horizontally_emitting.low_freq.vertically_emitting) and up to 20 dynamically located streams. The audio is then rendered for the speakers configurations. Highest-end decoder can theorically support 24.1.10 but I never saw a decoder support more than 32 channels.
My receiver has 13 outputs (11 amplified, 2 sub at line level) but I use a 5.1.2 configuration, in a relatively small listening room, and I don't know where I could add more speakers without rebuilding the walls and the ceiling.
But at thousands of speakers you don't need as much amplification for each wire and considering how these flat speakers are produced, it's not too unlikely that we could eventually be able to embed chips/controllers into then just like we do with current display tech.
With that setup you could encode hundreds of channels in a single wire and each embedded controller would be responsible do decode it's addressed channel(s) to send to it's respective "speaker(s)". If the signal produced isn't high enough, you may also add in some small amplification stage in the embedded chip.
Very interesting. While I disagree with the implementation details, you do bring up a great point I completely missed. Embedding electronics into these would be trivial, thus enabling some form of smart communication removing the need for discreet amps and removing most of the labor involved in installation. Man I love HN.
Angular resolution is all very well, but what about spatial resolution? Even from the same compass bearing, a noise coming from a mile away sounds very different than someone whispering in your ear.
20 milliseconds at the 99.5 percentile and five-nines (99.999) of uptime. Those are our goals for our globally-distributed permissions system as a service. If you’re interested in helping us achieve these goals, we would like to talk. We’re currently using best-in-class open source solutions on the public cloud for delivering this vision: Kubernetes, CockroachDB, PostgreSQL, Prometheus, Pulumi, Cuelang, Let’s Encrypt, etc.
As part of our small team, you will help to build our application platform, delivery pipelines, data architecture, and the application itself. You should be passionate about both software development and infrastructure. In this role you will be required to code. You will also participate in our on-call rotation which is responsible for the health of our highly-available globally-distributed service.
About the Company
At Authzed, we’re solving application permissions. We’re building a highly available, highly reliable, multi-tenant permissions system as a service which is deployed globally. Modeled after Google’s Zanzibar, our core open-source component SpiceDB is revolutionizing the way developers build powerful, flexible permissions into any application. With our founding team formerly of Red Hat and CoreOS, open-source is deeply ingrained in the fabric of our company.
I think it's more about the direction of the water vapor than the fact that the masks can pass vapor. If there was no leakage one might expect vapor to leave through the mask uniformly or in the same pattern as it did without masking (e.g. mostly forward.)
https://bigthink.com/strange-maps/parking-lots-eat-american-...
> Detroit was, or is, Motor City. Its center can pull off another automotive-related nickname: Parking Central. Fully one-third of downtown Detroit is dedicated to letting cars do what they’re not designed for: standing still.