Hacker Newsnew | past | comments | ask | show | jobs | submit | mistursinistur's commentslogin

> 2/3 of households own their own homes

1. "Household" is not the right unit of analysis, since a household is defined as the set of people in an existing home. Some of these include adults who would like to move out, creating a new household not accounted for in your denominator.

2. According to the U.S. Census Bureau, the average American moves approximately 11.7 times throughout their lifetime. In other words, current homeowners generate demand for housing just as non-homeowners do.


FWIW I've seen noticeably better results on (1) and (4) extracting JSON from images via Claude, although (2) and (3) still take effort.


Thanks for sharing.

I'm curious about what types of source documents you tried, and whether you ever suffer from hallucinations?


I'm building wooden benches for bus and light rail stops in my neighborhood.

Lots of riders are elderly and find themselves sitting on the curb, feet in the gutter, as they wait for transit. Studies suggest that perceived wait time increases by 30%+ when riders are forced to stand while they wait. There's no cheaper way to shave several minutes off of perceived trip time, for every trip.

Inspired by https://www.latimes.com/entertainment/arts/miranda/la-et-cam....


I have such a hard time relating to this. In Denmark I feel like 95% of bus stops have some sort of bench, and a lot of them has like a small shed, to get out of the rain in bad weather. It's wild to think that citizens should be adding those themselves. But I guess there's no profit in adding benches to each stop as a bus company.


> It's wild to think that citizens should be adding those themselves.

Antipathy towards the homeless ends up harming other citizens: "If we add a bench there, the homeless could sit/sleep there, and we'd have to look at them". The result is lack of benches, or ones that are incredibly user-hostile.


I used to live in Southern California. Many bus stops have no bench and no weather protection. It can get brutally hot without shade, and since it's a drought area, lots of people get caught without clothing for inclement weather. I think it almost criminal that there's at least no covering for these stops, much less a bench to help wait out such conditions.


I love this.

I've been through so many places where it's nearly impossible to find a place to sit for free. You just walk and walk and walk, until you're ready to spend 4-6$ to sit inside a business.

Benches have no economic value. You just sit there for free - you loiter - for as long as you want with no expectation of buying anything. Yet they provide undeniable value to their users.

I've made a habit of mapping benches on Open Street Map. Have you considered adding yours there, or updating the bus stops accordingly? StreetComplete lets you do it easily.


I really shouldn't ask and then pick favourites, but between you and me I love this.

Now that you've made me think about this, I can only place one bus stop with a half covered "perch" within a few kilometres of my house. All of the others are just a sign in the grass verge, or a wind exposed perspex cover in a couple of cases. Sadly, it hadn't even occurred to me how unhelpful that it is for many of the people that rely on busses.


I'm just curious about the logistics-- so are you allowed to just put a bench down at bus stops, legally? No one removes them?


IMHO you succeeded the moment you installed the first bench.


Good to know there are decent and kind people out there :-)


Silly to say without evidence that preventing some people from doing their jobs somehow creates more jobs for other people. H1-B visa holders aren't competing with workers in the retail services industry!


All transit projects in San Francisco are actually combined sewer, power, and water projects with transit branding. Better Market Street's budget incorporates all these components: https://www.sfcta.org/projects/better-market-street


I love using Gitlab SCM, but I'm surprised that Gitlab CI is described as "Lovable" while major bug fixes are gated for months on an uncertain future feature release:

"Job marked as success when job terminate midway in Kubernetes" https://gitlab.com/gitlab-org/gitlab-runner/issues/4119

IMO a production CI bug that falsely reports success merits a high priority patch release but Gitlab doesn't seem to see it that way.


This bug took too long to fix. We are not happy how we prioritized the last few releases for CI. In 12.4 we'll focus on fixing 8 of outstanding CI bugs https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...


So, can you shed some light on how the actual prioritization works? There are some bugs, one specifically I've mentioned elsewhere, that just get infinitely shoved into the void.


The Product Manager (in the case Jason Lenny who is out of office today) prioritizes between bugs, vulnerabilities, new features, and tech debt. He or she uses customer input, user input, and company input. Read more on https://about.gitlab.com/handbook/product/#prioritization

To find the relevant Product Manager see https://about.gitlab.com/handbook/product/categories/


So, the unfortunate reality of prioritizing customer wants like this is that you're always going to focus on big shiny new features, and not quite so much the smaller (while still important) bug fixes that really need consideration I feel. I felt like I got shoved into a black hole, and it does not inspire faith in your product anymore. Even if I did become a customer, which I was seriously considering before this, we're going to be "too small" to make a dent compared to your bigger customer base.


Existing customers tend to prioritize stability (fixing bugs) over new features.

Please note that even if you're not a customer our issue trackers are open so you can @mention the Product Manager to help them understand the severity and help to diagnose and fix things if you're so inclined.


As seen in https://gitlab.com/gitlab-org/gitlab-runner/issues/4029, a few people did show frustration, and why. And then began the never ending push back after push back.


I agree this issue hasn't been prioritized as high as it should. I meant to indicate that with "This bug took too long to fix." but I should have said it took to long to schedule.

We concluded the same internally recently and hence the focus on bugs and wider community contributions in 12.4. We overly focussed on getting the DAG https://docs.gitlab.com/ee/ci/directed_acyclic_graph/ and Merge Trains https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipeli... out the door and missed a bad bug, we're sorry.


Not a GitLab user, but I'm deeply impressed with your openness in handling issues on this thread.


I've always appreciated how open he is, I just wish it never came down to having to flag him down on Hacker News to get something properly fixed (although, I appreciate that is still something I can do).


Hi - just wanted to confirm that this issue has been addressed and will be included in our 12.4 runner release.

MR: https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...


PM optimizes for his own KPIs, which are at exec level. Given the history of ignoring bugfixes and becoming famous for it, clearly direction leadership sets gives no incentive to fix customers problems.


Hey, I'm Jason - the PM director for this area. I really do appreciate the pings - you can @ me at my username jlenny in issues that are important to you. It's true in general, even for features, but especially for issues a heads up helps us make sure we are prioritizing things in the right order.


You had already been involved in the issue, from what I recall. I also did state my dissatisfaction when it just continued to get pushed back. I get it, bug fixes aren’t glamorous and it’s not fun to work on them, but they still need to happen.


Getting Gitlab CI to work has been a major PITA for me. I would maybe give it a quarter circle in its current state. Not a heart.

The runner self-modifies the config file and uses it as state which makes it basically impossible to deploy it in an immutable way (Like on nixos). I found out that most config options (but not all of them) are also avaible as environment variables and cli flags so that's how I hacked around the issue but it means I can't support all features that the runner has because the environment variables do not expose all the available config options.

The fact that it's so hard to automate a piece of (in theory) stateless software is really annoying :(

https://gitlab.com/arianvp/nixos-gitlab-runner https://gitlab.com/gitlab-org/gitlab-runner/issues/1932 https://gitlab.com/arianvp/nixos-gitlab-runner/issues/2


Luckily they started to adapt Kubernetes themselves and some good improvements are underway from this doogfooding.

In particular UX of a runner registration was improved with config template feature https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...

There is still a problem, that self modifying config option doesn't fit nicely with Nix though


It's described as Lovable due to the measurements they make on real user behaviour. So people must be using it and sticking with it.


Rent controlled duplexes are already protected by the regulations that were violated here. You can't remove rent-controlled units without a permit!

Obviously some onlookers don't understand current laws and don't understand the proposed legislation. It's important for them to know that their trust in the legislator to do this for them is misplaced.


Like notacoward's post below, this one misses the point. The shaming is not about how good or bad or complex you are.

Some people have determined that Facebook is an organization that's producing some bad results. Socially shaming employees, removing the status they might have hoped to acquire and spiking attrition are tools being deployed to change Facebook's behavior and the behavior of Facebook's competitors.

You might claim that this pressure will never work, or that it will cause Facebook to shut down the "Are You Safe" feature, or gut the charity tools, or avoid developing these kinds of projects in the future. But we should avoid hand-wavy claims that Facebook and the people who work there are just too complicated to influence.


This misses the point of completely. This shaming is not about how good or bad you are.

Some people have determined that Facebook is an organization that's producing bad results. Socially shaming employees, removing the status they might have hoped to acquire and spiking attrition are tools being deployed to change Facebook's behavior and the behavior of Facebook's competitors.

You might claim is that this strategy can't positively affect Facebook's incentives, operations, or effects. But nobody should be distracted by navel-gazing or fancy philosophizing.


This key graf at the end describes why it's a bad demo that may cost taxpayers a lot of money:

"The result is that the tunnel would have negative value to the region. As a transportation service based on how Musk wishes to construct and operate it, it has practically no value. But in the event of upzoning in West Los Angeles, the tunnel would complicate any possibility of rail under Sunset connecting Hollywood with Downtown. Metro may even need to acquire and demolish Musk's tunnel, or else dig under the tunnel, which would complicate intermediate stations in Silver Lake and Echo Park."


> the tunnel would complicate any possibility of rail under Sunset connecting Hollywood with Downtown

Which I'm sure is right around the corner, guys.


I think he's really reaching there. As a tech demo, this tunnel is not that important in the long run (low hours, low traffic, only used for entertainment traffic) and so could easily be shut down if something better is put in later.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: