litchralee

I'm also old, but I understand people do watch portrait videos. Sometimes a lot of them, in a single sitting. There's a popular social media app which exclusively has short-form portrait videos.

Some charging pads also prop up the phone at an angle, making it easy to read the screen while also not having to hold the phone up. Most phones have their charging port on the bottom, so a phone stand couldn't be used while charging with a cord.

This 100%. The other comments addressed the "should I withdraw?" aspect of OP's question, but this comment deals with "should I stop contributing?". The answer to the latter is: no.

The mantra in investing has always been "buy low, sell high". If the stock market is down, continuing your 401k contributions is doing the "buy low" part.

Am I to understand that "maxValue" could have been named "maxOffset" and "minValue" be named as "baseYear"? I am indeed horrified at their inability to name something properly.

When you can still use code from a license and distribute the end result under a different license, that means they are compatible. Just like the MIT is compatible with any other license.

Your definition of license compatibility matches mine, as well as with how the term is used by the GNU Project and by the Apache Software Foundation. But I have a minor disagreement with the assertion that the MIT Expat license is compatible with any other license. And it's an important distinction, before I circle back to MPL and BSL compatibility.

The MIT Expat license is, by its own terms, very simple, and crucially allows 1) "sublicense" of the software, and 2) requires the copyright and permission notices to be included with copies. I assert that sublicense means that new license terms can be attached to a copy of such MIT Expat software, but under no circumstance can the new license terms abrogate the requirement about the copyright and permission notices. That is to say, a sublicense of MIT Expat software is void if it either: a) forces the obliteration of the Expat copyright or permission notices, or b) the terms of the new license does not allow for introducing code which wasn't originally licensed under that new license.

For example, when mixing MIT Expat software with GPL software, the resulting combination must be GPL licensed. This is what the GPL's copyleft provisions demand, and this is a valid sublicense of the Expat portion, per what I wrote above. Specifically, GPL doesn't command that the resulting combination to obliterate the copyright and permission notices, and GPL does not prohibit bringing more code into the GPL universe. Hence, MIT Expat and GPL are compatible.

But suppose instead that I've invented my own license, let's call it Litchralee's Interesting Terms (LIT), based on the WTFPL. LIT is quite simple, and adds one proviso which the WTFPL doesn't have:

0. Do WTF you want.
1. Any and all licensing text must be truncated beyond 100 Bytes for ease of understanding.

With this invented license, LIT is one of the (very few) licenses that is incompatible with the Expat license, because the mix of MIT software with LIT software must yield a result that is Expat licensed or LIT licensed. But neither is possible: to honor the Expat license for sublicensing the result means ignoring LIT's proviso #1. To honor LIT's proviso #1 for sublicensing means a full copy of the copyright and permission notices from the Expat license cannot be provided. Therefore, LIT and Expat are not compatible.

This will certainly seem like an edge case, and it certainly is, since the MIT Expat license is otherwise very, very permissive. But it's not all permissive. Its short text must be honored to the same degree that the comparably-larger GPL license must be honored, and the same goes for MPL and equally so for BSL.

In my previous comment, when I said that the MPL and BSL are incompatible, I believe that is still the case, because MPL+BSL => BSL is not an allowed combination, per the text of the MPL itself. As I laid out above, a work that combines two licenses must honor both, but if Hashicorp attempted to incorporate OpenTofu's MPL code into Terraform's BSL codebase and force the BSL license onto that imported OpenTofu, that is a violation of the MPL even if it doesn't violate the BSL.

We can look to the MPL's own text for why MPL+BSL => BSL isn't permitted. The relevant sections are:

1.5. “Incompatible With Secondary Licenses” means that the initial Contributor has attached the notice described in Exhibit B to the Covered Software; or that the Covered Software was made available under the terms of version 1.1 or earlier of the License, but not also under the terms of a Secondary License.

3.3. Distribution of a Larger Work You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s).

1.12. “Secondary License” means either the GNU General Public License, Version 2.0, the GNU Lesser General Public License, Version 2.1, the GNU Affero General Public License, Version 3.0, or any later versions of those licenses.

Taken together, the MPL does allow for MPL+X => X, but only if: 1) the original MPL software did not include Exhibit B, and 2) X is any of the GPL, LPGL, or AGPL licenses. A brief look at the OpenTofu LICENSE file does not show that they've included Exhibit B, but the BSL would definitely fail the second test, since BSL is not in the list of secondary licenses. That is to say, the MPL's own terms explicitly state its compatibility with GPL, LGPL, and AGPL, and no others.

So Hashicorp cannot "steal" the OpenTofu code back into the closed, proprietary realm of the BSL.

But Hashicorp could still use/incorporate OpenTofu MPL code into Terraform, provided that they honor the rest of the obligations of the MPL

This, however, is what they could do instead, and it means that Terraform would be BSL-mostly with some MPL OpenTofu code.

So they are benefiting from improvements made in OpenTofu.

Hashicorp can use OpenTofu in the manner given in OpenTofu's license, the same way that you, me, Microsoft, or the province of Quebec can. Open-source software benefits everyone and excludes no one. Is the suggestion that a special license be created, one which might be named "Screw Hashicorp Software License", whose terms disallow one specific organization? That's a rhetorical question, I admit, but if OpenTofu adopted an exclusionary license, that then means they must throw away compatibility with GPL, among others, because that license doesn't allow for sublicenses that exclude anyone.

An example of an exclusionary license -- with very good intent -- is the Anti-Caplitalist Software License, which is a non-open source, exclusionary license against corporations. I have other technical and practical issues with this license, but we're not here for that. Had OpenTofu adopted something like the ACSL as their license, any and all GPL plugins for Terraform that wanted to migrate to OpenTofu would be dead: GPL and ACSL cannot be distributed together, under GPL's terms.

In other words, any developer contributing to OpenTofu is donating work to IBM

Had they moved new OpenTofu contributions to a strong copyleft license

Part of the deal with copyleft licenses is that they create a perpetual one-way ratchet: the universe of copyleft code cannot shrink, always retaining the original grant of terms forever and ever, for all subsequent contributions per whatever license was used. GPL is regarded as one such "strong copyleft" license, but even it provides an out: separate distribution. Had OpenTofu used GPL, HashiCorp could still make use of OpenTofu within their BSL Terraform, by distributing OpenTofu as its own binary. Would this be silly? Yes, absolutely. So has Hashicorp been stopped with a strong copyleft license? Not at all; it's merely an inconvenience.

All the popular copyleft licenses cannot prevent Hashicorp from making some sort of use of OpenTofu. OpenTofu very much wants to preserve compatibility with GPL. OpenTofu would also like to remain FOSS if possible. The answer then is exactly what they chose: keep using MPL.

Using the tools of the capitalist (copyright and licenses) to wage a battle against a corporation is neither an even fight, nor is it even winnable. Instead, strong communities build up their skills and ties to one another to fight in meaningful ways. But that's getting too close to my complaints about the ACSL.

A word of caution for anyone cutting out the slot: make sure there aren't other instructions, like capacitors, ICs, and NVMe drives in the way of where the PCIe card will be.

The manufacturers that have the slot pre-cut will have already reserved the space, but even then, it's on you to check that it's suitable for a x16 if they only reserved space for a x8 card.

stay in a license that still allows Hashicorp / IBM to benefit from community contributions?

I don't see how this is the case. As Hashicorp explains, they switched from the open-source Mozilla Public License 2.0 (MPL) to the proprietary Business Source License (BSL) in order to apply restrictions upon users of Terraform:

Organizations providing competitive offerings to HashiCorp will no longer be permitted to use the community edition products free of charge under our BSL license.

The terms of the MPL and BSL are incompatible, insofar that Hashicorp cannot unilaterally relicense MPL code from OpenTofu into BSL code in Terraform. But Hashicorp could still use/incorporate OpenTofu MPL code into Terraform, provided that they honor the rest of the obligations of the MPL.

This is exactly the same situation as what Hashicorp was obliged to do before the licensing kerfuffle, so it cuts against Hashicorp's objective: why continue developing legacy Terraform if OpenTofu is going to provide continuity? Perhaps they only intend to develop new, exclusive features that build upon the common legacy code, but users would now retain an option to reject those pricy add-ons and just stick with the free, open-source functionality from OpenTofu.

It seems to me less about giving the finger to Hashicorp and more about giving users a choice in the matter. Without OpenTofu, the userbase are forced into the BSL terms of Terraform, where Hashicorp could unilaterally prohibit any production use by yet another license change. That's no way to live or work, with such a threat hanging overhead. OpenTofu lifts that threat by providing competition, and so maybe does kinda throw the finger at Hashicorp anyway.

On the flip side, precisely because MPL code cannot be unilaterally relicensed to BSL, if OpenTofu starts to gain new features that Terrarform doesn't have, Hashicorp can incorporate those features but they won't be unique. Why would a paying customer give money to Hashicorp for something that OpenTofu provides for free? The ecosystem of features cuts both ways.

Finally, it gives Hashicorp an out: if they acquiesce in future, their BSL code can be unilaterally relicensed as MPL once more, thus allowing code sharing with OpenTofu. Had OpenTofu picked a different license, this could have been much harder. But as described in the OpenTofu manifesto, continuity was the goal.

I'm ashamed to admit that in my head, the chief reason for why I can remember that "Crassus = rich" is because of Francis Ford Coppola's 2024 film Megalopolis, which has a character based on Crassus and has the same family name. The film is... an experience IMO, and was a major flop at the box office.

The other memorable name from that film -- entirely tangential to this community -- was the character Wow Platinum. It's a bizarre film.

SEIM? Do you mean SIEM, Secure Information and Event Management?

I can understand the pessimism in some of the answers given so far, especially with regards to the poor state of American public transit. But ending a discussion with "they guess" is unsatisfactory to me, and doesn't get to the meat of the question, which I understand to be: what processes might be used to identify candidate bus stop locations.

And while it does often look like stops are placed by throwing darts at a map, there's at least some order and method to it. So that's what I'll try to describe, at least from the perspective of a random citizen in California that has attended open houses for my town's recently-revamped bus network.

In a lot of ways, planning bus networks is akin to engineering problems, in that there's almost never a "clean slate" to start with. It's not like Cities Skylines where the town/city is built out by a single person, and even master planned developments can't predict what human traffic patterns will be in two or three decades. Instead, planning is done with regards to: what infrastructure already exists, where people already go, and what needs aren't presently being met by transit.

Those are the big-picture factors, so we'll start with existing infrastructure. Infra is expensive and hard to retrofit. We're talking about the vehicle fleet, dedicated bus lanes, bus bulbs or curb extensions, overhead wires for trolleybuses, bus shelters, full-on BRT stops, and even the sidewalk leading up to a bus stop. If all these things need to be built out for a bus network, then that gets expensive. Instead, municipalities with some modicum of foresight will attach provisos to adjacent developments so that these things can be built at the same time in anticipation, or at least reserve the land or right-of-way for future construction. For this reason, many suburbs in the western USA will have a bulb-out for a bus to stop, even if there are no buses yet.

A bus network will try to utilize these pieces of infrastructure when they make sense. Sometimes they don't make total sense, but the alternative of building it right-sized could be an outlandish expense. For example, many towns have a central bus depot in the middle of downtown. But if suburban sprawl means that the "center of population" has moved to somewhere else, then perhaps a second bus depot elsewhere is warranted to make bus-to-bus connections. But two depots cost more to operate than one, and that money could be used to run more frequent buses instead, if they already have those vehicles and drivers. Tradeoffs, tradeoffs.

Also to consider are that buses tend to run on existing streets and roads. That alone will constrain which way the bus routes can operate, especially if there are one-way streets involved. In this case, circular loops can make sense, although patrons would need to know that they'll depart at one stop and return at another. Sometimes bus-only routes and bridges are built, ideally crossing orthogonal to the street grid to gain an edge over automobile traffic. In the worst case, buses get caught up in the same traffic as all the other automobiles, which sadly is the norm in America.

I can only briefly speak of the inter-stop spacing, but it's broadly a function of the service frequency desired, end-to-end speed, and how distributed the riders are. A commuter bus from a suburb into the core city might have lots of stops in the suburb and in the city, but zero stops in between, since the goal is to pick people up around the suburb and take them somewhere into town. For a local bus in town, the goal is to be faster than walking, so with 15 minute frequencies, stops have to be no closer than 400-800 meters or so, or else people will just walk. But too far and it's a challenge for wheelchair users who need the bus. Whereas for a bus service which is purely meant to connect between two bus depots, it would prefer to make a few more stops in between that make sense, like a mall, but maybe not if it can travel exclusively on a freeway or in dedicated bus lanes. So many things to consider.

As for existing human traffic patterns, the new innovation in the past decade or so has been to look at anonymized phone location data. Now, I'm glossing over the privacy concern of using people's coarse location data, but the large mobile carriers in the USA have always had this info, and this is a scenario where surveying people about which places they commute or travel to is imprecise, so using data collected in the background is fairly reliable. What this should hopefully show is where the "traffic centers" are (eg malls, regional parks, major employers, transit stations), how people are currently getting there (identifying travel mode based on speed, route, and time of day), and the intensity of such travel in relationship to everyone else (eg morning/evening rush hour, game days).

I mentioned surveys earlier, which while imprecise for all the places that people go to, it's quite helpful for identifying the existing hurdles that current riders face. This is the third factor, identifying unmet needs. As in, difficulties with paying the fare, transfers that are too tight, or confusing bus depot layouts. But asking existing riders will not yield a recipe for growing ridership with new riders, people who won't even consider riding the existing service, if one exists at all. Then there's the matter of planning for ridership in the future, as a form of induced demand: a housing development that is built adjacent to an active bus line is more likely to create habitual riders from day 1.

As an aside, here in California, transit operators are obliged to undergo regular analysis of how the service can be improved, using a procedure called Unmet Transit Needs. The reason for this procedure is that some state funds are earmarked for transit only, while others are marked for transit first and if no unmet needs exist, then those funds can be applied to general transport needs, often funding road maintenance.

This process is, IMO, horrifically abused to funnel more money towards road maintenance, because the bar for what constitutes an Unmet Transit Need includes a proviso that if the need is too financially burdensome to meet, they can just not do it. That's about as wishy-washy as it gets, and that's before we consider the other provisio that requires an unmet need to also satisfy an expectation of a certain minimum ridership.... which is near impossible to predict in advance for a new bus route or service. As a result, transit operators -- under pressure by road engineers to spend less -- can basically select whichever outside consultant will give them the "this unmet transit need is unreasonable" stamp of disapproval that they want. /rant

But I digress. A sensible bus route moves lots of people from places they're already at to places they want to go, ideally directly or maybe through a connection. The service needs to be reliable even if the road isn't, quick when it can be, and priced correctly to keep the lights on but maybe reduced to spur new ridership. To then build out a network of interlinking bus routes is even harder, as the network effect means people have more choices on where to go, but this adds pressure on wayfinding and fare structures. And even more involved is interconnecting a bus network to a train/tram/LRT system or an adjacent town's bus network.

When they're doing their job properly, bus routing is not at all trivial for planners, and that's before citizens are writing in with their complaints and conservatives keep trying to cut funding.

Did an LLM/AI write this article? It says so much, but tells so little. Every link in the article is either to an irrelevant story or is inapplicable to Orange County, California. What are the "speed limits and precise definitions" being implemented? Why is Stockton mentioned? That's a city in San Joaquin County, hundreds of km to the north of Orange County.

Purchasers of electronic bikes operating in Orange County must shift their behavior in accordance with the upcoming April regulations

What is this? "Electronic" bike? The word used by basically everyone is "electric bike". And I don't even know if "shift their behavior" is a poorly-landing bike pun or an attempt at summarizing this "article". What concrete things should a resident in Orange County be doing now when considering a purchase?

I'm not sure I learned much at all from this.

have bandwidth that is some % of carrier frequency,

In my limited ham radio experience, I've not seen any antennas nor amplifiers which specify their bandwidth as a percentage of "carrier frequency", and I think that term wouldn't make any sense for antennas and (analog) amplifiers, since the carrier is a property of the modulation; an antenna doesn't care about modulation, which is why "HDTV antennas" circa 2000s in the USA were merely a marketing term.

The only antennas and amplifiers I've seen have given their bandwidth as fixed ranges, often accompanied with a plot of the varying gain/output across that range.

going up in frequency makes bandwidth bigger

Yes, but also no. If a 200 kHz FM commercial radio station's signal were shifted from its customary 88-108 MHz band up to the Terahertz range of the electromagnetic spectrum (where infrared and visible light are), the bandwidth would still remain 200 kHz. Indeed, this shifting is actually done, albeit for cable television, where those signals are modulated onto fibre optic cables.

What is definitely true is that way up in the electromagnetic spectrum, there is simply more Hertz to utilize. If we include all radio/microwave bands, that would be the approximate frequencies from 30 kHz to 300 GHz. So basically 300 GHz of bandwidth. But for C band fibre optic cable, their usable band is from 1530-1565 nm, which would translate to 191-195 THz, with 4 THz of bandwidth. That's over eight times larger! So much room for activities!

For less industrial use-cases, we can look to 60 GHz technology, which is used for so-called "Wireless HDMI" devices, because the 7 GHz bandwidth of the 60 GHz band enables huge data rates.

To actually compare the modulation of different technologies irrespective of their radio band, we often look to special efficiency, which is how much data (bits/sec) can be sent over a given bandwidth (in Hz). Higher bits/sec/Hz means more efficient use of the radio waves, up to the Shannon-Hartley theoretical limits.

getting higher % of bandwidth requires more sophisticated, more expensive, heavier designs

Again, yes but also no. If a receiver need only receive a narrow band, then the most straightforward design is to shift the operating frequency down to something more manageable. This is the basis of superheterodyne FM radio receivers, from the era when a few MHz were considered to be very fast waves.

We can and do have examples of this design for higher microwave frequency operation, such as shifting broadcast satellite signals down to normal television bands, suitable for reusing conventional TV coax, which can only carry signals in the 0-2 GHz band at best.

The real challenge is when a massive chunk of bandwidth is of interest, then careful analog design is required. Well, maybe only for precision work. Software defined radio (SDR) is one realm that needs the analog firehose, since "tuning" into a specific band or transmission is done later in software. A cheap RTL-SDR can view a 2.4 MHz slice of bandwidth, which is suitable for plenty of things except broadcast TV, which needs 5-6 MHz.

LoRa is much slower, caused by narrowed bandwidth but also because it's more noise-resistant

I feel like this states the cause-and-effect in the wrong order. The designers of LoRa knew they wanted a narrow-band, low-symbol rate air interface, in order to be long range, and thus were prepared to trade away a faster throughput to achieve that objective. I won't say that slowness is a "feature" of LoRa, but given the same objectives and the limitations that this universe imposes, no one has produced a competitor with blisteringly fast data rate. So slowness is simply expected under these circumstances; it's not a "bug" that can be fixed.

In the final edit of my original comment, I added this:

Radio engineering, like all other disciplines of engineering, centers upon balancing competing requirements and limitations in elegant ways. Radio range is the product of intensely optimizing all factors for the desired objective.