> I think if you install git for Windows, you get AWK as well.
Yes, but you also get perl there too.
4,146 karma · joined September 7, 2015
Yes, but you also get perl there too.
[1] https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/chan...
[1] https://www.youtube.com/watch?v=lBctnZ2phUw
[2] https://bora.co/wp-content/uploads/2015/12/bora_StanfordHuan...
Not sure about that[1], but acknowledged.
Graduate TAs were par for any course with a lab component or recitation, even courses that were taught by a lecturer; never felt like I was somehow being shorted opportunity in those though. It's the infamous adjunct part that my experience draws a blank on.
[1] https://fora.aa.ufl.edu/docs/10/2019-2020/Faculty%20Senate%2...
Somewhere in between, full-time lecturers (called "instructional professors" these days?) were and still are exceedingly rare (albeit probably safe to assert all ECE alumni of roughly the past 2 decades were Schwartz'd and/or Gugel'd in some capacity).
If OnwardMobility's eventual offering has a proper Blackberry-class keypad, it'll be an instant in for +2, and friend's wife will def be in for at least one as well.
Before that, several Curve variants. Still before that, Palm Treo 755p and 650. Despite the habit of always dropping them (out of lap and onto concrete/asphalt while egressing car), none ever actually broke...a bad (and expensive) habit to retain with smartphones, especially since having a protective case is a non-starter for me.
I'm clearly not the target audience here, but I'd be lying if there wasn't a sense of conceit in its objectivity...kind of like those World Book encyclopedia entries I'd read for hours at a time as a kid, becoming aware of the existence of something, but only enough to sow more questions than answers.
[1] https://electroagenda.com/en/a-summary-of-electronics/analog...
[2] https://electroagenda.com/en/a-summary-of-electronics/analog...
[1] https://cdn-codes-pdf.iccsafe.org/bundles/document/new_docum... 2017 Florida Residential Code Fig 301.2(4) Ultimate Design Wind Speeds V_{ult}
[2] https://cdn-codes-pdf.iccsafe.org/bundles/document/new_docum... 2020 New York Residential Code Fig R301.2(5)B Regions Where Wind Design is Required
[1] https://www.opm.gov/policy-data-oversight/pay-leave/salaries...
I think Framework has put together something that they believe has the potential to be profitable and I believe has the potential to be sustainable.
Nothing---especially with respect to obsolescence of consumer electronics---is without lifecycle risk to both a business and its customers. I choose to put my money where my mouth is now because I believe the problem is nevertheless worth trying to solve and the offering is good enough for my objective usecase.
Whether Framework can truly make their long term vision happen in a way that doesn't disillusion the community is obviously yet to be demonstrated. If the idea ultimately fails in the market, then such an outcome is hardly any worse than what I perceive to be an already regressive state of productivity laptops being overshadowed by consumption-centric mobile in at least the past decade, none of which ever focused on maintainability as critical design paradigm. Where I think the Framework meta truly differs is it lays a notebook form factor foundation that openly invites the hacker community to fill in at their leisure. Such a brazen "go fuck yourself" message to every other laptop vendor on the market earns my respect any day of the week.
Is it the best of all possible worlds? Probably not and there's surely room for improvement, but unlike most entitled consumers who want the future now for pennies on the dollar, that's not what I'm paying for either. I'm paying to support a sensible start towards something that the marketing and design of big companies intentionally ignore, have interim utility during a period of transitory company growth with hardware features and software (non-)options that I actually want, and hoping the rest of the market follows through with qualifying the movement's worth in the long run.
Merely speculating that FFC interconnect is "probably just a USB-C" says absolutely nothing of the fact that Acer's system is neither truly modular (because it's fundamentally constrained to specific I/O interface by its own case) nor externally reconfigurable by the user. Nevermind that Framework's design appears to sensibly apply what was intended to be floating interconnect (USB-C male) to a fixed peripheral module interface on both sides, which is a huge value add from a user configuration perspective on the merits of being able to choose what side your charger port is installed on alone.
So what about the enclosure being custom made?? Oh I don't know, nevermind completely disrespecting mechanical design considerations and effort applied towards targeted maintainability which have a direct impact on internal layout, user ease-of-self-service considerations that quite frankly the rest of the consumer laptop market clearly hasn't given an ounce of attention. That Framework completely own their tooling alone tells me substantial work was done.
Without even critiquing layout, Acer didn't even so much as give its prospective customers the courtesy of a fuckin' reach-around by soldering memory directly onto its motherboard and left a substantial amount of internal volume on the table. I suspect comparing display maintainability would be a complete joke of an exercise.
Basic understanding in laptops and modern electronics...yeah, sure.
This practicing hardware EE is far from convinced.
- topside (primary servicing end)
...and then there's:
- frontside (replaceable bezel, magnetic retention)
- underside (venting pattern, 6 less securing screws)
- keyboard layout (escape, arrows, tilde, backslash, left ctrl, delete)
- power button (location, fingerprint reader integration)
- peripheral support (modular af, reconfigurable, select your charger side)
- camera, mic (integrated lockout)
- lid opening extruded cut (narrower span)
- internals (design for maintainability of the highest order; so different it's not even worth enumerating)
- documentation (digital first approach, baked onto every sub-assembly)
Wish I could get a closer look at the bezel electronics. What other details did I miss?
The proper term "Technical Order" is indeed salient to the Air Force, but the notional concept of a "technical order" is precisely what the parent describes and exists in all branches of service, deriving its authority from a long traceability chain that terminates as a general order issued by the Secretary of the respective branch of service, e.g. in the Navy, its functional equivalent is a "Technical Manual".
I beg to differ on distinction. Whereas both uniformed and civilian personnel are required to comply with executing technical orders per the same chain of authority, the latter is almost completely shielded from the punitive hammer of the UCMJ.
I suspect the biggest general public barrier to entry here would be competing against a glut of qualified applicants with 5-/10-point veterans' preference, assuming time was taken to put notification hooks in place for immediate action on job postings that'll close almost as soon as they're announced.
[1] https://www.energy.gov/nnsa/downloads/nnsas-demo-pay-system-...
I grew up on a small island in the Pacific and played something similar[1] called chongka' as a kid as well.
I was one these longtime AT&T customers that jumped ship a month ago; I have several unlocked BlackBerry Key2 and essentially don't use data (roughly 1 GiB on any given month per unit over the past 2 years). The cost of these phones approach flagship territory, and there still isn't a suitable replacement on the market as integrated physical keypads go IMO, so it was a no-brainer.
That the much older KEYone and Priv models would continue to be supported on their network, yet the newer Key2 and Key2 LE models aren't on their whitelist despite supporting VoLTE and receiving an unusual number of system updates in the past year alone, was at first baffling. As I understand it now, the situation is a business decision (not tech constraint) to whitelist only older VoLTE-compatible models previously sold by AT&T---whereas the Key2 supposedly never was.
After all the periodic SMS reminders and dealing with their batshit annoying bot that would entitle itself to interrupting the first 30ish sec of my voice calls, I got really tired of it and burned a random Sunday afternoon porting over---saving over $300/yr per phone with still more than adequate data. Never looked back.
[1] https://www.att.com/support/article/wireless/KM1324171/
[2] https://www.att.com/idpassets/images/support/wireless/Device...
To be completely honest, this sounds like a classic case of conflating hardware revision and configuration as it pertains to a managed configuration item. That you didn't have access to approved internal schematics, and technical knowledge of the black box was constrained to a defined external interface boundary prior to independent reverse engineering efforts is certainly consistent with that.
Class II ECPs consistent with MIL-HDBK-61/SAE EIA-649-1 and the system's documented objective maintenance plan are a thing. Surely the SMR code of this controller (more specifically, its maintenance repair and recoverability disposition indices as specified by AR 700-82 [1] that logistics activity would have assigned it) in the context of reported anecdote would be sufficient to infer an interesting story.
I certainly don't doubt that you encountered 4 different harware revisions, but it strikes me as much more likely that the maintenance plan for said system never intended internal hardware abstraction layers to be serviced by activity at your level, instead structured to be independently managed by contract activity driven by performance-based logistics incentives with the objective of ensuring that, from a black box behavioral perspective, what they reindoctrinated back into the supply system is tested to be operationally indistinguishable ("form, fit, function" as it were) and thus compliant with overarching performance specifications when integrated at the next higher assembly level.
[1] https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN30303-AR_700...
The suggested notion that anti-tamper integration exists on arbitrary whathaveyou weapon systems is, at best, misinformed. Field updating of operational software at the box level over e.g. 1553, or ARINC 429 via 615, or even vanilla RS-485 PHY via bespoke protocol, is very much a thing and almost de facto mandatory capability for most systems. If we broaden the scope of the term "field" to include intermediate-level maintenance in forward-operating labs staffed by uniformed personnel, then even firmware updates of cherry-picked circuit card assemblies can be a thing (although much simpler isolation to a replaceable circuit card or modular assembly is a lot more typical; CCA-level firmware updating is usually reserved for depot or OEM activity).
> In general, military (electronic) gear is designed to be difficult to repair because repair and reverse-engineer are pretty similar.
Bullshit. In fact the exact opposite is almost always boilerplate baked into acquisition performance objectives, sometimes even down to defining explicit MTTR targets. Certain systems even modularize the anti-tamper crypto applique portion to enable repair of everything else that isn't anywhere near as sensitive and much more probable to fail based on analysis.
The real meta is an adversarial one where private defense contractors are intentionally exploiting a complex process with the objective intent of locking in the ever so lucrative OEM sole source sustainment dependency, and the corrupt influence on DFARS statutory language as it relates to technical data rights is a critical part of that game.
Ha...you've clearly never been a software engineer in the encumbered world of fielded defense systems.
Despite seemingly popular belief, uniformed personnel maintaining military equipment simply aren't at liberty to arbitrarily fix shit that breaks however way they please using whatever support equipment/material is readily available.
Think of it this way: the general order issued would be that all uniformed personnel must comply with the explicit language of technical orders in performing routine/unscheduled/critical maintenance of military equipment---no more, no less. In turn, said technical orders specify the applicable troubleshooting, diagnostic, repair, test, documentation, etc. instructions that maintenance personnel must follow and even describe system theory of operations (albeit fairly high level; nowhere near the level of specificity adequate for an engineer).
Consider this[1] junior Air Force crew chief. He's reviewing the maintenance records (specifically, 781A records which document discrepancies, related maintenance and their associated corrective actions; maintained in parallel with mirror digital database equivalent) of an assigned aircraft because he was trained in tech school on compliance of a certain mandatory technical order[2] to do so. Everything he and all his uniformed colleagues are tasked to perform is quite literally "by the book" (of which there are many) and to be executed without deviation. In theory, nothing is left to guess work and everything is traceable, all the way down to what pieceparts of a weapon system can/can't be serviced at specific levels of maintenance. Technical order doesn't exist? Can't do it. Demonstrated proficiency at a routine task? Doesn't matter; the applicable technical order must always be present, open at task and performed to the letter at all times. In this environment, you're not authorized to wipe the ass end of an aircraft without an explicit technical order enumerating step-by-step instructions. That maintenance officer screaming at this guy's senior enlisted supervisor is in fact a logistician in company-grade uniform. Said officer can steer this airman towards court martial for a serious enough technical order deviation, but really can't do shit if exhaustive technical order compliance doesn't result in a desired outcome.
In your example, the system would be deemed "not mission capable", the required part(s) would be placed on order (whose priority shot call would be determined by the production superintendent) and you'll move on to something else until the part(s) arrive and you're directed to resume maintenance action.
[1] https://www.defense.gov/observe/photo-gallery/igphoto/200245...
[2] https://www.tinker.af.mil/Portals/106/Documents/Technical%20...
The root cause of these issues (as I see it) is almost entirely traceable to tech data availability/quality, commercial influence on DFARS data rights language, and the acquisition games being played (of which the general public only every catches superficial wind surrounding ACAT I programs).
If you cared about digital decode only, and had confidence in both the SI of your interface and tooling, sure. Great when things "just work"...entirely unhelpful when they don't at the lower layers of hardware domain.
[1] https://www.keysight.com/us/en/product/D4000USBA/usb-2-0-tri...
..."for 100 stunning photos on each CD-ROM. $18.98 each" [1], just in case anyone else wanted to square the comparison in proper context.
[1] https://i0.wp.com/the-avocado.org/wp-content/uploads/2018/03...