I feel that people like Russell Ackhoff should be mentioned when exploring the topic of asking the right questions and understanding the right problems to solve (at Bell Labs):
1,022 karma · joined April 7, 2015
Some programs have had to supplement their CS-curriculum with courses incorporating instruction on software engineering practices (e.g. version control). The "AI" being sold today isn't going to replace these practices.
It appears the author/poster is using LLMs (OpenAI and Claude, specifically) to extract entity and relationship data to create a knowledge graph of French Restaurants and Chefs.
https://github.com/theophilec/foudinge-scrub/blob/0a2701756f...
It's worth mentionion that the Graph browser using "Retina" is a project from Ouestware (https://www.ouestware.com/en/) which is also contributor to the GraphCommons and GephiLite projects.
The game here is defining parts of the job away to be someone else's job or responsibility.
A starting point: https://youtu.be/yGN5DBpW93g
The issue with the above names is that they can be applied to a domain or area of practices, or an organizational boundary. In a non-trivial number of organizations, "DevOps" is viewed as a support entity for one or more software development teams, versus software development teams practicing "devops."
This applies to many of the *_Ops names in fashion during the past five years or so.
Pandas' use of the dataframe concepts and APIs were informed by R and a desire to provide something familiar and accessible to R users (i.e. ease of user adoption).
Likewise, when the Spark development community somewhere around the version 0.11 days began implementing the dataframe abstraction over its original native RDD abstractions, it understood the need to provide a robust Python API similar to the Pandas APIs for accessibility (i.e. ease of user adoption).
At some point those familiar APIs also became a burden, or were not-great to begin with, in several ways and we see new tools emerge like DuckDB and Polars.
However, we now have a non-unique issue where people are learning and applying specific tools versus general problem-solving skills and tradecraft in the related domain (i.e. the common pattern of people with hammers seeing everything as nails). Note all of the "learn these -n- tools/packages to become a great ____ engineer and make xyz dollars" type tutorials and starter-packs on the internet today.
It looks like in this 2022 blog post evaluating latency and throughput over Starlink, they concluded that PEPs were not being used in the Starlink network (and probably unnecessary) due to the lower latency characteristics from use of LEO satellites. They also mention that PEPs are (still) commonly employed by GEO-satcom based operators.
https://blog.apnic.net/2022/11/28/fact-checking-starlinks-pe...
In internet-style communications, such as routing IP traffic over satellite links to low-earth-orbit or GEO, with much longer round-trip times, link latency is substantially higher than most terrestrial wired or wireless applications and acknowledgements required as part of TCP take much longer to facilitate. PEPs as an example augment the connection allowing end-user/client devices in the network with inline-PEPs to retain their normal network settings and perform the task of running or starting sessions with higher TCP-window sizes, as a method for improving overall throughput.
The utility of a PEP, or PEP-acting device goes up when you imagine multiple devices, or a network of devices attached to a satellite communications terminal for WAN/backhaul connections as the link's performance can be managed at one point versus on all downstream client devices.
That's a bold claim. Is this a marketing post for selling courses?
The mobile jammer in the article's scenario is transmitting toward the satellite, not the terrestrial terminals on the ground.
Imagine in the primitive example case that the "real" signal transmission must also be coming from a terrestrial terminal as well. The real terrestrial terminal is likely be similar in size to the mobile jammer, and subject to the same kinds of constraints as the jammer. However, the jammer doesn't have to consider much about the quality of its radiated energy at the target frequencies. Let's also assume that that both the real transmission terminal and the jammer can emit the same amount of energy.
The distance between both the real transmission terminal(s) and the jammer to the communications satellite, for all practical purposes, is roughly the same.
From the primitive example communications satellite's perspective, it will see/hear both the real signal and an equally "loud" signal (noise) at the same frequencies. When the communications satellite relays or retransmits what it hears to the receiving terrestrial terminals, it will be the combination of what the satellite saw/heard.
Instead of the "bent pipe" imagine another primitive example where the communications satellite is an optical mirror, and the "real" signal comes from a light source on the ground pointed at the satellite. The "real" signal could be represented using different modulations of that light in brightness, frequency/wavelength, as well as temporal pulses. Terrestrial receivers decode the "real" signal based on the flashes of light it observes from the mirror. The jammer in this scenario is another light source pointed at the same mirror.
Terrestrial, ground-based jammers are not the only type of potential jammer in a satellite communications system's operational scenarios. In the prior example ground-based jammers look upward to jam the satellite. You can also imagine scenarios where airborne jammers are possible, which look downward to jam receiving terrestrial terminals.
A ground-based jammer versus an airborne jammer would have a few differences. The ground-based jammer mostly needs to consider a fairly well-known location of the communications satellite, as the satellite can be easily observed, and its future positions can be calculated using ephemeris data, for targeting. An airborne jammer would have to deal with the issue that it has a lower field of view than the satellite beam's footprint and needs to have more specification information about the location of terrestrial receiving terminals to apply its own area of effect, which would be smaller than the satellite's beam. However, the effective distance between the airborne jammer and terrestrial terminals will be orders of magnitude lower than the communications satellite and terrestrial terminals. Power transmission capacity is a constraint for all terminals, satellites, etc, and an airborne jammer's ability to apply power will be more effective than satellites due to distance, but the airborne jammer must be more selective on where to apply (i.e. target) that power.
One jammer could be used to affect the transmission signal, but it would likely take many jammers to target receiving terminals when there are many geographically dispersed terminals.
Received signal strength, from the point of view of a terrestrial satellite communications terminal on the ground/airborne/maritime can also vary based on where the terminal is located within the footprint of a communication satellite's coverage beam; it's typically strongest at the center of a beam.
The most primitive conceptual model for a communications satellite is often described as a "bent pipe," where signals transmitted up to a satellite from the ground are relayed as-received by the satellite back down to terrestrial receivers. In the linked article, the diagram reflects a concept such that: if a "jammer" can interfere with the transmitted signal to the satellite in a manner that the satellite cannot discern the true signal from noise contributed by the "jammer," what is relayed back down to terrestrial receivers by the satellite is "drowned out" because the relayed signal is now a combination of the true signal and sufficiently more noise contributed by the jammer rendering the communications channel and any signals over that channel non-viable (i.e. "jammed").
Historically there are a lot of revolving door style career moves, but usually from the direction of active duty officers going into industry roles. And in the last decade we've also seen the flow back in reverse direction (e.g. SecDef, technically a civilian office)
While it wouldn't apply to every person serving, it seems possible to have exposure to conflicts of interest if the person's civilian job directly intersects with the industry pool where systems are being developed and procured from.
I guess they asked ten employees this question. Nine were on H1B visas, and the tenth was already on Focus/PIP.
At Google, the vast majority of new college hires would begin as Software Engineers at Tech Level 3 (L3), where Tech Level 5 is "Senior Software Engineer." Level 6 is "Staff."
The terminal Level concept was one where all Software Engineers are expected to perform in an upward trajectory toward the standards of the next Tech Level, until reaching Tech Level 5. I.e. Software Engineers are expected to be promotable up to Level 5, and after reaching L5, there is no longer an "up or out" expectation. L5 SWEs are not expected to become Staff Engineers.
Today, the Terminal Level for Google SWEs is now Level 4.
The median Google SWE historically was around L4, and your average Google SWE would be a seasoned L4, potentially ready for a promotion to L5 in the next few promotion cycles.
The idea of a "principal" Software engineer is Level equivalent to a Director (Level 8) of which despite there being many at Google/Alphabet, as a percentage of the total population it is quite small.
"Arvados is a modern open source platform for managing and processing large biomedical data. By combining robust data and workflow management capabilities in a single platform, Arvados can organize and analyze petabytes of data and run reproducible and versioned computational workflows."
For example, should an automation fail, will manual processes still work? Does execution of a manual correction, or repair, require the knowledge or skills of a particular person or persons that may not be available, etc, or can it be done by the normal persons that the automation is intended to serve/benefit?
In the Smart Home context, when the automation or other cleverness fails, will ____ still be operable normally by a regular person?
https://coral.ai/docs/accelerator/datasheet/
It does not have VRAM as it is not a graphics card :)
There are examples and instructions for exporting Yolo variants to run on the Edge TPU: https://docs.ultralytics.com/guides/coral-edge-tpu-on-raspbe...