Hacker News new | past | comments | ask | show | jobs | submit | hijinks's comments login

they are planning to allow you to run your logs in your own datacenter/cloud and put something like a proxy there or being built into quickwit that your logs show up in the datadog UI

My guess is you will be billed per gig or something but not nearly the cost of shipping your logs to DD


too many people and not enough land in areas where people don't have to drive 3 hours to work.

Want pricing to go down then we need to build more dense housing even an hour drive from the city. The days of wanting a big backyard are coming to an end for most home owners.


> Want pricing to go down then we need to build more dense housing

You need mass transit and transport integration. House density can only move you so far (and it's not very far).


Luckily, density is what makes mass transit viable. It's more cost effective to run a driverless metro every three minutes in an urban core than to run a mostly-empty bus once an hour in a distant suburb.


> Luckily, density is what makes mass transit viable.

Up to some point, and it's not even that high...

What really makes mass transit viable is integration.


What if we put the jobs closer to the people instead of making the people get closer to the jobs? Just drop a big ol’ tech park in the middle of Oakland?


Who is the “we” in that sentence? Is there a Central Planning Bureau that forces “jobs” to be placed in certain locations? What jobs would you place near the people, whatever that means?


I often see comments in the theme of "dense housing is the panacea."

You can't really run power tools in dense housing, correct? Or fix stuff yourself? Sounds awful.


I was born, raised, lived in dense cities. I've lived in semi-suburban life as well. Unless you're into some hobbies that requires such tools, you just never use it? And when you have to... you just use it? I live in an apartment building in a city, and once a month or so, during daytime, people use tools and it's no biggie.

To each their own though. I definitely grew to understand that if someone was raised in rural or suburban life, it would be extremely hard to adjust to hardcore city life, and vice versa. But I don't think we should be blocking build ups for one, if there's demand.


We just bought a place in a dense area of The Hague, and I run a table saw + shop vac frequently as we renovate. No complaints yet, just keep my hours between 10-6. Lots of other neighbors doing similar stuff too.

There are lots of benefits to density. Our grocery store and day care are less than ten minutes away on foot, because there's a ton of people so we can support these kinds of businesses (also weed, hair salons, bars, cafes, boutiques, secondhand stores, restaurants, play cafes, etc etc.)


you can use the vscode cline to give a task and it uses a LLM to go out and create the app for you.

In django i had it create a backend, set admin user, create requirements.txt and then do a whole frontend in vue as a test. It even can do screen testing and tested what happens if it puts a wrong login in.


does anyone use this?

I'm really starting to get sick of companies that claim they operate at petabyte at scale and find you need to spend 400k a month to support that scale.


Thousands of active deployments globally.

How many open source log systems work at PB scale given any number of resources? Also FWIW, OpenObserve can ingest data at 28 MB/Sec/Core (We are working on optimizing it even more) and ingesting 1 PB of data would cost just $435 based on on-demand prices (AWS m7g family).


That doesn't answer the question of who? A (rightly) cynical reading of what you posted could just be "thousands of active deployments" you did for yourself to prove benchmarks.


Machines I would use for benchmarking would go down after some time and won't be active.


Still didn't answer the "who" part.


We will publish many names on our website soon.


Why is it only 28 MB/core-second?

Is that production rate, inbound bandwidth, rate to persistence, rate to processed, or rate to display?


Compute power is required to process and store the incoming data.

It's not "only 28 MB/Sec/Core". Try doing same with Splunk/Elasticsearch - You won't go past 5 MB/Sec/Core (Typically it will be lower) on their best day.


To what state?

Suppose I have 28 GB of trace data in memory on a machine and then I fire that off. What do I have after 1000 seconds?

Do I just have a file of 28 GB of raw trace?

Do I have 28 GB of raw trace in memory ready to be indexed?

Do I have a data structure in memory ready to be searched?

Do I have the full trace information rendered on my screen (or a aggregated visualization derived after processing all the data)?

If it is the first, that would be ridiculously slow. If it is one of the latter ones, then it would depend on what querying operations are fast.

28 MB/core-second makes no sense without the context of what you can do quickly after the “processing” is done.


Too much to give all details in an HN thread. To simplify the conversation, Data will be persisted and usable for individual searches and aggregations. I would welcome you to our slack workspace for any further questions you may have - https://short.openobserve.ai/community


solar costs keep shrinking and then you have power companies like SDGE that want to punish solar owners based on their salary and set a $125 min cost to be connected to the grid


I don't think utility companies are entirely wrong to charge some flat rate for being connected to the grid, there are fixed costs with each customer and solar homes are not actually independent from the grid even if they're net neutral their night time power has to come from somewhere. Even if we get to enough residential solar to completely power the grid from solar and charge enough storage to last overnight there's still the costs associated with storing that power overnight we can't get around.


The trouble with this logic is that public utility commissions across the country have measured the impact that solar has on the grid, and found that not only does it not impose a cost, but it confers a benefit, in some studies up to 33 cents per kilowatt hour.

I completely agree with your core point, which is that there need to be costs associated with impact on the grid, to make sure that there's no incentivization of freeloading in either direction. Whether utilities owe solar owners a one time payment, an ongoing payment, or should be contributing to the financing of new construction of solar panels is an open question imo.


Source please? I'm aware of the large costs in the opposite direction due to the freeloading you mention:

https://energyathaas.wordpress.com/2024/04/22/californias-ex...


This is from the Maine PUC, other PUCs across the country do their own studies. Maine is on the high side, but all but one PUC that I'm aware of have calculated positive values.

https://www.utilitydive.com/news/maine-puc-study-values-sola...


That link is from 2015, so I suspect it's talking about benefits at very low penetration.

Clearly things become very different at very high penetration. I mean, if everyone is net metering, who is consuming the excess power? Who is paying for the power plants that these people use when not providing their own power? The economics would go all to hell.


I think we'll have to go to floating rates for bought power to solve that. If there really is no where for the power to go the price of power from solar should fall to zero or below. The economics of your night load plants/storage gets tricky then though because you're losing time when you would currently be making money to solar but they still need to exist to provide power during the night or when there's bad weather all day and you don't get much solar power.


I think the utilities are moving very early with their flat rate charges but I don't think they're wrong in the long term that a flat rate will be required to fund the grid in the future. I'm thinking about the point where a large majority of customers have sufficient solar generation to cover their entire energy usage for the day on average, those people still need generation or storage of power during the night when solar doesn't work so somewhere they'll need to continue paying for power generation or storage during the night. This is probably doable with time based rates instead but we'll have to see and even then we'll probably need some flat rate to account for people with local storage because they also exist as a cost to service.


So as I mentioned in my previous comment, public utilities commissions across the country have all run their own independent studies of the value of bringing solar on the grid measured against its costs and generally found it to be a net positive rather than a negative. Those studies encompass things that you're talking about such time base rates, cost of mobilizing peaking and base load production, efficiencies from consuming power on site instead of having to send it through the transmission and distribution system, etc


I'm not talking about now. I thought I made that clear enough but I'm talking about in the future with extremely high levels of solar self sufficient customers. All of those need power during the night so absent huge grid storage you'll need nuclear or hydro to provide reliable night time power all of which costs money.

I'm all for massive solar investments it's a great path forward but there are issues we'll have to address.


No one wants to hear it, but this is the case. We need to revamp how we charge for electricity.

A flat fee that accounts for all the fixed costs that the grid requires, then an additional fee based on usage. There is no magical bullet that removes that. Maintaining lines and transformers and keeping it all monitored and balanced and so on takes money.

That will make it so solar is still viable without making utilities complete money holes.


1) Those fixed costs go down with more distributed generation. No need for large solar farms in a different zip code if many customers have it on their roof.

2) Many/most utilities don't pay retail rates for excess power, so there's already profit built into the arrangement with solar customers.

3) You didn't address a utility charging monthly fixed fees based on income.


1) They go down but not to zero. Consider a hypothetical person with excess solar and a large power bank, they still cost money to serve and build reserve capacity for when events require them to pull from the grid.

2) They don't and there was a LOT of complaining about not getting paid full rates by early solar adopters.

3) I'm fine with it. The power grid is one of the natural monopolies where state operation makes more sense than the weird quasi private marketless mess we have now and progressive tax structures are normal there so I don't see as much problem with income related grid fees. Also higher income people will generally have larger grid demands meaning they need more excess capacity built in so they probably do cost more to serve.


Utility companies around me will gaslight you into not getting solar--bury you in paperwork, FUD, and last ditch efforts to buy into some kind of solar timeshare program.

I'm hoping to see more decentralized/hyper-local power generation and storage.


>I'm hoping to see more decentralized/hyper-local power generation and storage

With the scale we're dealing with decentralization does not work. You need to centralize for efficiency (i.e. optimize power generation and maintenance per unit of land-area). Though in this case the point is moot, since we don't have any grid-scale storage solutions for wind/solar - making them non-viable as the primary power generation regardless of price.


>decentralization does not work.

This is not quite true, because the vast majority of solar generation is consumed on site, avoiding the transmission and distribution costs of delivering electrons that would normally be necessary. Which is just one of a whole motley of dynamics working in favor of solar at larger scales: the arc of solar generation over a 24hr period almost perfectly coincides with actual market demand over the course of the day, with the exception of the afternoon/evening "duck curve", so it's actually relieving pressure on peaking generation.

The important fallacy here is assuming that counterbalancing for the cycles of solar generation requires new investments, when in fact it's relieving pressure on infrastructure that already exists and is already serving those exact counterbalancing purposes. This is in addition to the benefit of offsetting alternative forms of base load generation.

To be clear you are right in an important sense about a pretty fundamental thing. There is indeed a tipping point, and when we reach that tipping point of grid penetration all of the points you have raised will indeed become not merely relevant but crucial. And I forget the exact number, but my understanding is we're nowhere near that tipping point right now. I want to say around 20% of the overall grid being generated from solar power is the tipping point but I'm not sure if that's accurate.

It's kind of like the argument sometimes people want to make about taxes which is that if you overtax it is a drag on the economy, which is hypothetically true but it's true at a given tipping point and it's a tipping point that we're not anywhere near, which doesn't tend to stop the advocates from bringing it up all the time.


> the vast majority of solar generation is consumed on site

I don't believe this is true for a vast swath of residential solar. In spite of HN's love of remote work, a lot of homes are mostly or completely empty during the day, with energy use ramping up in the evenings as people return home.

This results in homes 'selling' electricity to the grid during the day, and buying it back in the evening and overnight.


That's true in many (but by no means all) cases now, but it's a short term problem. Home batteries with capacity for a day or more's usage are on track to hit affordability in the next 5 years, which will remove this problem.

There is also a lot of scope for demand shifting. For example, timing washer and dryer runs during the day when people are out. Or running AC during the day (even if nobody is home!) so that it doesn't have to work so hard in the evening.


as a parent it would be fun to have my kid sit in the middle seat between two random people and let them deal with him on the flight while I relax far away


This is basically the main plot device for the movie Home Alone.


I fly first class - the kids fly economy.


Take a look at quickwit. Its basically a clone of elasticsearch but in rust.

I have around 380 TBs of logs currently in s3 and have sub 1s searches for needle in the haystack searches. It handles all that with just 5 search nodes running on kubernetes with 6gig of RAM each.

I'm ingesting around 20TBs of logs a day on it.


pghero and/or https://github.com/supabase/index_advisor

If you want to pay for a saas then pganalyze is like $400 a month for 4 dbs is a pretty good pricing model


its a lot of warm moisture that comes up the coast from the southeast and slams into cold air from canada and can drop a lot of snow/wind. It can cause bad storms in the ocean and high seas.


as someone that has been remove for 10 years now and interviewed a lot of people.

You can 100% tell when someone is reading off a screen and not looking at you during an interview via webcam


I'm not sure if you read the post, but with some of the new cheating tools that exist, they overlay the GPT responses in front of your screen with concise bullet points. You wouldn't even need to look away from your screen or interviewer to cheat. The bullet points are also small enough to where it is incredibly difficult to tell that someone is reading anything - even if they have a webcam enabled and are looking right at you. This, coupled with some interviewers that don't care a lot about the process, it is getting easier for cheaters to slip into places for sure!


Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: