Ukraine has about 2000 small ISPs in the country as opposed to half a dozen extremely large ones in the US. While a very large ISP has more resources to stop attacks, the sheer number of separate small systems there that need to be attacked seems to be an advantage to me.

I remember the day (actually very very late at night) that I was finally able to compile Mosaic on the Amiga 500 and look at a "modern" web page ie a headline, some text and a jpeg image. At the time it was a pretty big accomplishment and very exciting.

Oh, and get off my lawn.

It's true that you usually wouldn't need to connect a monitor to one of these, but during development sometimes it's handy to just hook up to it like a small desktop and poke around. It really has to be hdmi because there are no monitors around that support composite any more. As long as you can somehow disable the ports/pins/resources that the hdmi uses when you're done, I don't see any harm in it. Just my 2 cents though....

when they all play the same thing? Generic music, generic news, generic humor.

I'm going to be surprised if they find any.

Holy Fire by Bruce Sterling. Extremely interesting look at how an ageing mind and a youthful body might interact together.

While encryption is prohibited in amateur radio, I believe that some radios do have encryption available on them (mostly the chinese radios). Generally they can't get FCC approval for the radios that allow illegal behaviour, but they may be using a loophole because some of the radios are also used on the commercial bands which may (???) allow encryption.

I think most of the posts are correct that this has come about because of the over reach of h265 patent holders' demands for money. I have to assume that they can change their licensing terms at any time though. If it looks like they are losing business, it would make sense for them to drop their prices, just like any business venture would.

If the cost of using h265 suddenly drops to the range of using h264, I have to think that at least the speed of progress would slow for the open solution(s). I have to believe it's really hard to create a codec that is performant and doesn't (arguably) infringe on alleged patent rights. At some point, some of the companies in this alliance may decide it's not worth the cost of doing more development if it's just as cheap to pay mpegla (or whomever) to use h265.

I really think that it's good news that this is happening because of a business decision in addition a moral decision. It makes it a much easier sell to the PHB, but as business situations change, business decisions must also change. I really hope that there is enough conviction in this project to overcome issues that have kept previous solutions from following through.

It will cost 3 million dollars and no one over 40 will be able to figure out how to open the door.

The higher current draw (if a low voltage DC is used) will require much heavier cables than the typical (for US) 12 guage cable. That can get expensive and there would certainly be the need for DC-DC converters for funky voltages. Maybe it would be standardized over time but that's a long way off.

Maybe there will in fact be something like a 48V standard that would be some sort of compromise, although I think the Tesla batteries run around 220V to keep the motors relatively small. I don't know if there's any real problem with running higher voltage DC in the home although I'm pretty sure switches would need to be made differently to prevent arcing.

Seems like maybe more trouble than it's worth.

One plus is the ability to tether. I have to pay an extra $50 a month with Verizon for a jet pack. This would cut that out entirely.

I hate to admit it but I am an AV guy, for a very long time. Passing around a wireless hand held mic (or even one with a wire if you can't afford W/L) is the only good solution. A cheap mic 4" from your mouth will sound better than an extremely expensive mic 4 feet away.

A fairly decent W/L mic from Shure is a bit less than a grand (a really good one is about $4000). You can get a W/L mic from a cheapo audio catalog for a few hundred bucks, but if you really can't afford a decent one, I'd suggest getting a decent wired mic - maybe a hundred bucks tops. It's not that big a deal to pass around a wired mic if you're at a conference table and if the room is big, get several and put them on stands so people can walk up to them and ask questions or whatever.

If the problem isn't big enough to warrant spending much of anything, just have the main presenter use a mic & repeat any questions.

By the way, if you don't like how much newer mics cost, tell the FCC to stop selling off the white space frequencies that W/L mics use.

I am unclear if this would work for a "single stream" like a video webcast source in a remote location using multiple cellular links like jetpacks. I can easily see how any given network request would go to one link or another depending on availability, but I'm assuming that this would not be able to take a network video stream and parse out portions of it to the various uplinks and then at the far end put the stream back together (in order to get either extra bandwidth or extra reliability) to forward on to a server. Teradek and other companies have specific hardware & software to do this. Can this fault tolerant router be made to do something like this, either with or without additional software?

I will usually spend an hour or so looking for an existing solution if I expect it to take only a couple days to write the code. Even when I expect it to take a week or two I won't spend more than a couple hours looking around. The problem is that even if I find code that does pretty much what I want to do, it will usually take a day or two of screwing around with it to figure out how to make some required part of it work in my overall project. Maybe 95% will be just the way I need it but there seems to always be a gotcha that I don't find until I'm well into the project. Generally I just find that it's faster to do myself rather than try to bend someone else's code to work with mine.

A lot of it depends on what you consider correct. I work almost exclusively on amd platforms with opengl and am pretty happy over all with what I get. I have the reverse problem as you because supporting nVidia requires a lot of adjustment where amd and intel opengl work pretty much as is in my code. You can say that's because I'm doing it wrong and that nVidia has the proper implementation, but I think it's more that you get used to working with your own solutions and anything that requires additional work feels wrong headed in its design.