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

I think there is sulong for that (https://github.com/oracle/graal/tree/master/sulong)


What do you mean when you say it exhausts the heap? I understand that the stack size is fixed but can't the heap grow unbounded using sbrk till it exhausts the address space?


I think they mean that it grows to the point where it collides with the virtual address space allocated to another block (the stack, a shared library, a mmap'd area etc)


I don't know anything aboug tcmalloc specifically but if the program is not mapped at 0, then there's space below it as well. The heap can meet the stack using sbrk while memory below where the program is could still be mmapped. This was the case on x86-32 anyway. On x86-64 programs are mapped much lower (on my system anyway.)


> I'm pretty sure they meant recompiling binaries to be x86-64 instead of 32 bit x86

I don't see why you should think that given that the discussion has been pretty much about the uint32 nature of TransactionId.


Because OP said they didn't know anything about postgres and were speaking in generic terms, and the way they said "switching to int64" and recompiling all binaries just stroke me as "if you want a 64 bit system, you need to recompile it" (which is true). I'm surprised it's a compile time constant, as I just learned.

Reading their post history now they probably do know what they're talking about, though.


There's a reason for even database servers with 32-bit transaction IDs to be 64-bit processes - performance and memory. AFAIK until Firebird 3.0, Firebird also had 64-bit server builds with 32-bit transaction IDs - it would have broken many external tools had the old on-disk format been changed.


Ride of a Lifetime by Bob Iger is another which was a bestseller and also one I found rather insightful.


The bootlin training slides on embedded linux boot time optimisation is also quite informative: https://bootlin.com/doc/training/boot-time/boot-time-slides....


Same here. I certainly find the chronological listing better than an opaque algorithm. Also able to filter the top 20 posts of the day.



Ecosia (https://www.ecosia.org/) is a search engine based in Germany which spends most of its profits in reforestation efforts by collaborating with local non-profit organizations. They also publish their monthly financial reports here: https://blog.ecosia.org/ecosia-financial-reports-tree-planti...

Disclaimer: Not related to them in any way but recently came to know about them when they hit the 100 million count of trees planted.


>> I believe that a viable strategy for them would be to instead focus on making Firefox better than Chrome on everything else but the Google Stack. If the Firefox experience is better on all other sites, Chrome will be gradually marginalized.

Quite difficult when every developer I see is testing and verifying their product on chrome


Hi!

I use FF as my primary dev browser. The debugger lets it down and the JSON viewer in the network tab is annoying... but everything else is excellent. The CSS layout inspectors are particularly good.


On the JSON viewer being annoying: is the issue that it shows the information twice for all fields? That's what drives me crazy. I wonder how hard it would be for a newcomer to make a fix for this.


They just need a killer set of dev-tools.

What, of course, they've noticed and were working for already.


Good-quality dev tools seems to be one of the things they're abandoning in the recent layoffs: "In order to refocus the Firefox organization on core browser growth through differentiated user experiences, we are reducing investment in some areas such as developer tools, internal tooling, and platform feature development, and transitioning adjacent security/privacy products to our New Products and Operations team"


I always use Firefox personally during development, the dev tools are really great.

Our test suite uses Selenium with Chromium, which allows me to cover both browsers to some extent.


I think OP meant that companies, like Amazon and MS, whose projects are starting to depend on rust should be putting some resources. Although to be fair, Microsoft and Amazon do pay for their infrastructure if I am not wrong.


Right on both counts.


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

Search: