- yetiheheThose civilisations that make too much illogical choices probably die off.
- Now that you say that, I checked in bios and looks like you're right. I have 4 sticks of "DDR5-4800-16GB @6400MHz". It was probably marketing speed, but works stable and memtest didn't find any errors.
- Security checks will still be done because it may be even easier to take over the plane when you don't have to threaten a pilot.
- Looking at home computers, most of "computing" when counted as flops is done by gpus anyway, just to show more and more frames. Processors are only used to organise all that data to be crunched up by gpus. The rest is browsing webpages and running some word or excel several times a month.
- > DDR5 is available on AMD since 3 years and is 5600
Strange, I bought 64GB DDR5 6400MHz last year and apparently my motherboard can handle up to 7200MHz (or more with overclocking).
- Pipes moving water are cheaper than heat pipes, which are not "solid state", typically heat pipes contain a lot of water in liquid and vapour form under low pressure. If you wanted to move a lot of heat, you would need bigger pipes, which would need to withstand more force, so thicker. It's cheaper to just move that water with pump and if you place your inlet in proper place (higher than your machinery), you could even get some energy from flow of water.
- > The demographics have nothing to do with that, [..] changed when it becomes mainstream.
So it's not unreasonable to say that when demographics of forums was changed, the economic incentive appeared? So it actually depends on demographics?
- It's "Cosmic latte". https://en.wikipedia.org/wiki/Cosmic_latte
- > The rest of the satellite must be within the shade of the solar panel,
Problem is with solar panels themselves. When you get 1.3kW of energy per square meter and use 325w of that for electricity (25% efficiency) that means you have to get rid of almost 1kW of energy for each meter of your panel. You can do it radiatively with back surface of panels, but your panels might reach equilibrium at over 120°C, which means they stop actually producing energy. If you want to do it purely radiatively, you would need to increase temperature of some surface pointing away from sun to much more than 120°C and pump heat from your panels with some heatpump.
- > 2 m2 panel makes about 500w
It receives around 2.5kW[0] of energy (in orbit), of which it converts 500W to electric energy, some small amount is reflected and the rest ends up as heat, so use 1kW/m^2 as your input value.
> If we run the radiators at 80C (a reasonable temp for silicon), that's about 350K, assuming the outside is 0K which makes the radiator be able to radiate away about 1500W, so roughly double.
1500W for 2m^2 is less than 2000kW, so your panel will heat up.
[0] https://www.sciencedirect.com/topics/engineering/solar-radia...
- Water in mains pipe is typically colder than your house walls (where the pipes go). So you need to flush some water from your pipes to get that colder mains water.
- So what? "Hardworking" is a choice. You can choose to be hardworking or not. If you are already hardworking, then you can use your luck. If you're not, you will squander any chance.
- Maybe intelligent species have a lot of variance? There are good and bad dolphins, like there are good and bad people.
- ... and Russians will find new reasons not to shoot their drones, which they will happily share with EU residents via social networks. They are the masters of excuses.
- It is not TCP based. In Erlang processes have mailboxes. But they don't have promises, you send a message and wait for response with timeout or do something else. And TCP is only used between nodes (vm instances). But you can use any communication channel (UDP, unix sockets, tls, serial port, some other process doing funny things).
> Its' interprocess communication is TCP based in general case and because of this is faulty.
What? It's faulty because of TCP? No, in Erlang it is assumed that communication can be faulty for a lot of reasons, so you have to program to deal with that and the standard library gives you tools to deal with this.
- It doesn't. It's "promise" based, not "communicating sequential processes". Erlang has more preemptive scheduling, a "thread" can be preempted at any time, here you can only be synchronized when you wait for result. It is called "actor-based", because only functions tagged as "actor" can call waiting functions.
This is more node.js-like communication than erlang.
- Air bearings run dry until they get some moisture. Then they fail. Old joke about making radio enclosures: make it as watertight as possible, then drill a small hole on the bottom to let the water escape.
- My home construction slipped 6 months on 2 year build time. It happens in construction very often.
> software is only tougher to estimate if incompetent people (vast majority of the industry, like 4+ million) is doing the estimating :)
No, it is tough to estimate, but not only for incompetent people. And "incompetent" can be stretched to "don't know what he's doing", which is how I operate most of the time. I don't know what really needs to be done until it's done. Main part of my work is research on what actually needs to be done, then "just" implementing it. If I waited with estimating until I know what needs to be done, I would spend 3/4 time estimating and then 1/4 with clear understanding and good schedules (example description: I will be clicking keys for 5 hours).
- 10 days was already after I used this algorithm. Previous several tasks on that codebase were estimated pretty good. Problem with this is that some tasks can indeed take SEVERAL orders of magnitude more time that you thought.
One of the hardest problems with estimating for me is that I mostly do really new tasks that either no one wants to do because they are arduous, or no one knows how to do yet. Then I go and do them anyway. Sometimes on time, mostly not. But everybody working with me already knows, that it may be long, but I will achieve the result. And in rare instances other developers ask me how did I managed to find the bug so fast. This time I was doing something I have never before done in my life and I missed some code dependencies that needed changing when I was revieving how to do that task.
- I think software is one of those VERY rare things, where inaccurate estimates can actually be inaccurate by "orders of magnitude". After 20 years in the field, I still managed to use 2 months of time on a task that I estimated as 10 days.