Depending on the application, I think “without preprocessing” is a huge assumption here.
LLMs typically do a terrible job of weighting poor quality context vs high quality context and filling an XL context with unstructured junk and expecting it to solve this for you is unlikely to end well.
In my own experience you quickly run into jarring tangents or “ghosts” of unrelated ideas that start to shape the main thread of consciousness and resist steering attempts.
It depends to the extent I already mentioned, but in the end more context always wins in my experience. If you for example want to provide a technical assistant, it works much better if you can provide an entire set of service manuals to the context instead of trying to put together relevant pieces via RAG.
As a Brit that relocated to Norway a decade ago, trust me when I say you cannot fathom the lack of organization around identity that the UK (somewhat intentionally) has. (It’s constantly used for political Godwin’s-law fear-mongering)
There is no centralized ID number, the closest is your social security number but this is basically only outbound for PAYE tax and haphazardly correlated to your pension payments in late life.
Everything operates on a “trust system” where you often present paper (!) with whatever address you claim to be living at as proof you are real (e.g. opening bank accounts).
Passport loss is rectified by seeking out “professionals” with government-approved occupations that are not related to you that can vouch you are actually the person you are trying to replace a passport for.
The entire thing is a mess and living in digital-identity-native Europe is a dream come true that you should be extremely thankful for.
>>There is no centralized ID number, the closest is your social security number
Until you find out that due to a cock up years ago the National Insurance numbers are not guaranteed to be unique, and you realize that somehow the best proof of identity British people have is a humble driving licence because DVLA is at least somewhat competent.
It's even worse now: A lot of places now accept PDF's of things like bank statements, since so many people don't get paper copies any more.
It's not that it was hard to fake before if you wanted to, but when you can just get a real PDF as a starting point, and edit it slightly it's just theatre.
It doesn't have to be perfect. This is how financial regulation works in the US too, but it does work. The idea is that every individual step is weak, but it's a crime to bypass any of it. So the deterrence is you can catch things probabilistically and most people don't want to commit a whole bunch of crimes at once because they all have individual punishments.
B-but... if we have an ID card the "government" will be able to track us! /s
It does annoy me how much people get away with scaremongering, I just read a comment of someone who's against digital payments because "then the government will be able to work out how much tax you owe"????
> the execution of JS code it down to the browser rendering the page where it’s deployed. As such it’s practically impossible to get any code to run consistently
Can you elaborate on this part?
I would say one of the strengths of JS is that you can get it to run consistently just about anywhere.
Certainly! Now, I’m no expert and may get some things wrong here, if anyone else knows better I’d be happy to be corrected.
Every browser implements a version of ECMAScript (this is a specification declaring what features of the JS language will be available for the JS engine included with the browser).
This means that every browser on the planet, and every version of them, support different JS features.
For example, let and const are commonly used to define variables, but if someone happens to use an old browser version the use of these would cause an error, which in turn may cause all the rest of JS code to stop executing, resulting in (worst case scenario) your website being rendered useless to that particular person.
On top of that different browsers may use different engines. So even if they define the same ES version the code may still execute differently (this was for example a very big issue with Microsoft browsers in the past).
This may seem trivial, but new JS features emerge all the time. Granted, this was a much bigger problem before ~2015 something, but it’s by no means none existent today.
Thus, you cannot be sure the code you write locally will actually function the same everywhere, and you are unlikely to know how often failures even occur since it all happens client side.
I think with the official deprecation of IE this is mostly a thing of the past since all major browsers are “evergreen” and support a pretty recent standard. This certainly was the case only a couple of years ago, and it’s almost always wise to have a bundler (e.g webpack) that can target a fixed standard as output via transpilation/polyfill just in case you are itching to use the experimental features.
I know you're not entirely serious, but we really had it good and largely figured out with tables. It's probably because using tables for layouts was my native language, but I still sometimes have to mentally translate divs into a table in my mind to picture what is happening, and when default types are change (like block to inline, etc) it sometimes breaks my brain and I have to fallback to experimentation to get what I want. Slight disclaimer though: I'm a backend/infra guy so don't do frontend very often.
Tables aren't even deprecated. IMO you're better off keeping the tables than transforming it into <div> soup. 20 years ago you'd hear it shouted from the rooftops: "Tables for layout are not semantic!". Guess what? <div>s are never semantic. Just use tables if it suits you.
If you want to remove the semantics of table elements, you could set a role="presentation" attribute on all table-related tags. I'm wondering what HTML semantics enthusiasts will say about this. ;-)
You almost got me. After all why not? So I had to go read stuff, and think more about it than I would have. So thanks for this.
So: <table role="presentation"> is probably mostly fine, but not great, and not good practice.
The ARIA spec [1] says:
> 2. Notes on ARIA Use in HTML
> 2.1 First Rule of ARIA Use
> If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
That's because simpler is easily more accessible. ARIA is last resort, when all else failed. ARIA is complex and not always well implemented, or implemented at all, and when it is implemented, interpretations can differ. Your content will be more accessible to more users / for more browsers if it doesn't rely on ARIA to be accessible. And more often than not, you can do more harm than good by using aria attributes, because it's easy to misuse them, which is worse than not using them at all. Now, ARIA is still very useful and should be used when it improves things over what HTML/CSS supports by itself, but table-based layouts have readily available HTML/CSS solutions.
My opinion is that there's no good reason today to use tables for presentation. One of the reasons is always the same: separation of concerns. Structure your content, in the simplest possible way, and then style it. Structured content, with a structure that's as simple as possible, is more easily accessible. Add divs if really necessary for styling (which don't really change the structure, since they don't have meaning - keeping in mind that they are a compromise).
It's funny how everyone seem convinced by the principle of separation of concerns, except for HTML/CSS/JS.
You could use divs with display:table(-row|-cell) for the same result. Although CSS flex or CSS grid would let you achieve the same thing with a simpler structure and will allow you to have a responsive design. Fat tables with side menus are unwieldy on small screens and your <table><tr><td>-based structure will make it more difficult to offer a usable design to them.
Table layout are also not great on text / terminal-based browsers. Letting the content flow from top to bottom will be way better. You have this for free if you don't use tables, because usually terminal browsers don't understand CSS.
I would then reverse the question: why use tables when you can use display:table, CSS Flexbox or CSS Grid? What are the benefits? Especially when they are simpler as soon as you learned once how to do your favorite layout using these "new" things. I won't be convinced by any answer that sounds like "I don't really want to learn this stuff" because if we are trying to answer "What is the most correct way to do this", we should seek to use the better version, not the one we are familiar with.
It seems to me "Why not use <table role=presentation>?" is a bit like "Why not use this carafe labeled 'this is a glass' as a glass?". Sure, why not, it will work, but if you have a glass now, even if you need to pour the water into the glass before you can drink it, isn't it better? (of course, maybe not the best analogy, I'm not good at analogies, but I hope it can help understand my perspective on <table role=presentation>).
I also believe role="presentation" or role="none" is a code smell. It has legitimate uses (I guess), but the use better be clearly justified.
one is a table the other pretends to be a table. There has to be a lot wrong for the table to forget what it is. try disabling style.
css also gets complicated much faster than html. I like to offload complexity to less complicated areas.
a practical example: i look at each row and set rowspan for duplicate values. a series of rows might have week 22 as their first cell and multiple with monday as their second.
How about "one pretends to be a layout, and the other is a layout"?
I don't understand well what you are saying, but:
> a practical example: i look at each row and set rowspan for duplicate values. a series of rows might have week 22 as their first cell and multiple with monday as their second.
This seems to be a case of using a table as a table, which is fine. You should use tables when you are trying to represent tabular data.
This seems to fall under the unconvincing "I don't really want to learn this stuff". This seems to be the only reason people are tables for layouts today.
People doing this are probably not interested in the rhetorical efficacy of the justification. In other words it probably doesn't matter whether you find it convincing.
Counterpoint: no semantics is better than wrong semantics. If a screenreader thinks your layout is a (data)table, it makes your visually impaired users sad.
I lost out on a front end job about 15 years ago because I marked up a business’s open and close hours in a table during a coding test. I was told that my skills were clearly out of date.
If you use tables for what they were intended for or you have no problem with them, keep on truckin. But they sucked when they were the only way to do things.
Table are used when tables are needed. Excel like overviews. No reason to not use tables.
For site layouts (multiple columns etc) you would better use divs in a flexbox or something.
Who needs Flexbox's inscrutable 1-dimension language when you can use ASCII diagrams in CSS Grid for clever 2D things easily? CSS Grid Kids are truly spoiled.
It is almost a shame modern browsers no longer support all the fun layout patterns of ol' FRAMESET. There was a layout tool to cut your teeth on (possibly literally the way it was made out of browser chrome).
Not that I necessarily advocate for frameset insanity, but you know what? That is a shame. My controversial (?) opinion is that browsers should literally never break anything that was once a part of the web platform unless there's simply no other choice. If the size of it is getting too big... first, stop adding more shit. (And then maybe, implement some old features in terms of some newer ones. Not really "web platform" but I am a huge proponent of what Ruffle is doing for the web.)
I’ll go a step farther: improved frames and datasource-aware tables and lists with a few very basic features found in almost any other UI kit out of the box would have given us 99% of the actually-beneficial stuff AJAX did, but better.
The Web is a ton worse because we decided to build apps on it but never built the tools to do it right, even though the building blocks were right there.
IMO the biggest problem with the way frames works is that it doesn't work well with navigation. I think unfortunately that this is just a design flaw with frames and it needed breaking changes to mitigate.
I think I would've rather seen it go that direction, but it's hard to say. Without a crystal ball, we can't really compare the outcomes, and it's hard to imagine what would've happened in this hypothetical. I mean, I don't think in 2004 I would've been able to guess (or stomach) what the web was going to become 20 years down the road.
I can't agree with this, because it creates a "barrier of entry" for people building new browsers. Old things should deprecate when new things do them better, and deprecated things should phase out.
Otherwise, we're stuck with Chrome Forever. I'd rather not.
Disagree. Deprecating things like <frameset> will not make it easier to build new browsers. Shadow DOM and WebComponents are significantly more complicated for browsers to implement than any old "deprecated" technologies. If you don't want Chrome forever, what you want is not removing old technologies, it's preventing more new technologies from becoming a part of the web platform.
We'll get better at building software. Even with huge engineering teams, we can only build the browsers that we have today due to improvements in large-scale software engineering.
Framesets still work as far as I know, they're just no longer recommended for a few reasons. Browsers already try very hard to never ever break anything, at least not anything that's been commonly supported for years or has made it into a standard. The main places browsers have broken compatibility with old content are related to plugins like Flash and Silverlight, which were always controlled by a single vendor instead of being open standards.
> at least not anything that's been commonly supported for years or has made it into a standard.
It's more: has made it into a standard and was commonly supported.
Sadly, the browsers aren't trying hard enough not to break anything. They are trying hard not to break anything standard, but the problem with that is that the standards can change, or that some things can be claimed to never have been standards all along. A bunch of IE/Netscape things have broken already such as BLINK and MARQUEE, despite being common enough to "feel" standard even though yes they were never actually standards. Also, as we've seen with the MathML battle in recent years, even standards aren't guaranteed to be kept in browsers if not "commonly supported".
The MDN deprecation warning on FRAMESET:
> Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes.
The browser support table says that every browser still currently supports FRAMESET with simple COLS and ROWS, but as I recall FRAMESET used to also support more complicated layout tools. My brain recalls it as being very similar to TABLE layout at one point in time that you could also have (limited) COLSPAN and ROWSPAN options. Such things may also have been IE/Netscape era "non-standards". If I had examples, they are probably lost to time. Similarly, with nearly no way to easily search in today's indexes for things specifically from the 1990s I can't think of a good way to find old examples either. It's also possibly my memory is just failing me on this and the crazy things I recall doing with framesets were just table layouts after all and maybe iframes, but I do recall doing some crazy things in the 90s that certainly aren't "standard" today and I know wouldn't work in today's framesets.
Yeah I don't really count Flash or Silverlight as parts of the "web platform" personally, though I will re-iterate that I am still very pleased with the Ruffle project nonetheless. From a practical standpoint, Ruffle does a lot of good even if Flash always was proprietary and not really a part of what the web platform really was at its core.
I hope <frameset> continues to work into the future. I'm sure eventually it will wind up on the chopping block, and personally I think that'll suck.
Although there is some degree of silliness to suggesting table layouts in 2024, it frankly really is not that bad. To me personally, the era of float: left and clearfix and 10 layers of wrapper divs was significantly more of a mess. "Oh look, I got my layout working on IE6! Oops, it's now broken in Opera..." Anyone remember using invalid CSS to write browser-dependent styles? How about using Microsoft's proprietary DirectX filters to make PNG transparency work? In the era of taking crummy PSDs full of graphics and chopping them up into images for an HTML template, these were the tools of the trade.
Not that tables were perfectly standardized or anything, because I do remember Netscape and IE not totally agreeing on how to handle column widths, but they sure were, well, simpler.
Yeah, but HN uses tables in a really dumb way. Each comment is in a separate table with the width of the first column set to provide the correct amount of indenting.
If the comments were properly nested you would just have a standard left margin and the tables would be completely unnecessary.
Worth remembering that airlines don’t handle your luggage themselves and instead contract it out to ground handling companies.
It would be more interesting to map flight carriers/numbers to handlers (e.g. Menzies) and regions to give a more reasonable blame/availability overview.
I would think it's more likely that luggage handling is centralized at major hubs. For example, there was the infamous Denver Airport Baggage System that was plagued with issues and has been the subject of much analysis [0].
Forgot to answer your actual question: Delta does directly handle its ramp operations at ATL, as well as at BOS, CVG, DTW, MSP, MIA, and SEA. But in the US there are state and federal labor laws to consider and where possible, they, like the other major airlines, offload a lot of staffing generally to Unifi or similar specialist staffing agents. Unifi used to be part of Delta until spun off and sold around 2018 if I remember correctly. Beforer then they were called Delta Global Staffing and primarily handled temp hiring. Now it is 49% owned by Delta but covers hiring for United and Alaska and a few others where possible, and provides the training and certs and all that as well, temp or full time, where possible, including some ramp positions at ATL. SLC, LAX, LGA, JFK are all Delta hubs and positions for ramp agents are entirely absent on Delta's career's page, but on Unifi there are pages and pages that cover almost everywhere in North America where Delta flies. Compare Unifi's open careers page: https://unifi.avature.net/careers to Delta's: https://delta.avature.net/en_US/careers and it should be pretty obvious as to the difference.
This is a bit of generally not very useful osint info but a subdomain search on HR platforms can reveal at least to some degree the labor situation at a lot of entities. avature has over 4000 subdomains in their dns records on securitytrails alone. Not all are for staging or VPN access or SMTP. Some are no longer active, but most do resolve. That's medium potatoes at best compared to the 10k+ at bamboohr. Although if you are doing OSINT you're probably not going for a job at a lot of these staffing agencies anyway. Ever since I was asked to leave a Cutco presentation in 2011 I haven't applied for a job since and I've been poached multiple times and am basically retired at 37. But this is a neat trick and I like dataset gathering for its own sake, and it definitely gives off an interesting view of the economy that may or may not reflect how any one feels about how things are going.
(If I need a job, I prefer fangraphs or baseballprospectus anyway, but they aren't hiring anyone who filed tax returns as professional gambler, sadly)
I know that it at least differs between the US and Europe. I've known ramp agents in a few countries and in the US the contracts in the end are handled by the airlines and training/regulation is governed by the FAA. The couple of European ramp agents are ultimately contracted to the airport (or really, the entity that operates the airport). This is a small sample, but there definitely exists more than one model of how ground staff is managed that is the norm. To further complicate things, the company that pays you may be a subsidiary of the airline you work for or sometimes a different airline or group of airlines, operating under a different name.
I'll give you an illustrative example that hopefully demonstrate how convoluted things can get. Swissport is one of the largest ground services providers in the world. It was first split off from Swissair as its in-house ground service department and became an entity under the holding company SAirGroup in the mid 90s, after plans to merge several of the flag carriers of smaller European countries fell apart when Swiss citizens voted not to join the EEA and therefore, denying Swissair of access to both 5th freedom rights in the EEA and potential cabotage rights. A few years later shortly after 9/11 the airline collapsed as did the holding group which resulted in Swissport being sold off to private equity (Swiss International took over operations on the airline side, sort of, by virtue of a Swiss government bailout and the acquisition of Crossair, the regional arm of Swissair that was divested earlier, by the creditor banks, but in a ton of debt and had to recoup as much as possible. Swissport continued operating after it was sold off and maintained relationships with, well, eventually just about every major airline through mergers and acquisitions, Crossair became Swiss International and was taken over by Lufthansa in 2005. Swissport has maintained relationships with Swiss through Lufthansa but only provides full service to Swiss at ZRH and cargo service at Basel (which Swiss pulled out of in 2015 on the commercial side, and also, is actually located in France, at least airside). It also handles regional operations for Lufthansa out of Munich. ZRH is the main Swiss hub and also a Lufthansa hub, but the fact that Swissport provides full ground service there is almost happenstance since Swiss serves over 100 other destinations and Swissport over 200, many of which overlap, but they do not directly serve the airline elsewhere except cargo operations to Basel. But there is another major airport in Switzerland, and Swissport operates there, but Swiss and Lufthansa Group uses dnata as their handling agent, a subsidiary of Emirates. dnata has no presence in Basel and is a minority operator in ZRH, where Swissport handles something like 80%+ of all ground operations. If you fly Swiss to just about anywhere else in the world, you'll see Swissport, but they aren't likely, save for some prior arrangement where airlines with limited presence may agree to contract through another airline, to essentially provide service in a separate agreement, but these are more ad hoc and subject to change and affects relatively few flights in comparison.
Lufthansa had its own ground services arm that it sold off - LSG Sky Chefs. Gategroup, which owns Gate Gourmet, was the Swissair catering service until being spun off in the same mid 90s expansion that ended up in the collapse. Swissair is no longer an active brand, but it is still valuable to an extent, so it is licensed out, although I have no idea where - like how Pan Am got licensed out to a freight rail carrier, it's likely stamped somewhere random and unrelated to Switzerland or air traffic, but brings in revenue so, why not?
I rarely fly now and when I do, it's domestic US and by charter. That's a whole other crazy mess but somehow, less messy than the scheduled airline industry and far less problematic than the duopoly both having supply chain issues, as both Airbus and Boeing currently does. That's on the news, if you haven't been paying attention, and it's not going away for a bit, by the looks of it. Air travel, meanwhile, remains safer than driving.
I did the same thing, used to fall asleep reading the strategy guide for at least a year before I got the game myself.
I was similarly absorbed with those annual “bumper collection of cheats for video games” books that used to come with tech magazines, endlessly rereading them and memorizing them for games I never owned.
I wonder:
A) How much this is endemic to the Hacker News demographic. I’ve always been absorbed in the pursuit of useless knowledge (later in life this manifests in unnecessary PC watercooling and Haskell addiction).
B) If we all had genius parents that realized you can spend £3.50 (much less than the cost of an A list game) and keep a child occupied for an entire year, while also encouraging them to read (!!).
Children are learning machines, they will devour anything you give them... whether it's "useful" or "useless" is an adult judgement, or perhaps even a judgement on your deathbed?
There are plenty of quiz tournaments and quiz shows, and whole communities of general-knowledge recallers called "quizzers", ultimately because _other_ humans are impressed and entertained by displays of mental prowess. Is knowing every Pokemon or every x86 instruction any more or less useful than knowing test cricket results or every Beatles recording?
is batteries-included because every language model worth their salt is already able to create markdown and it’s very tempting to utilize this in order to provide layout and break up the wall-of-text output.
I’m all in favour of lowering emissions for the 1% but it’s a strange place to draw the line when their calculations suggest ~70% of emissions come from “the Everyman” that is 1st-33rd percentile. Cheap and plentiful access to lower carbon technology will be 4x the impact of focusing on the top percentile alone, even if it doesn’t fit the narrative.
Personally, I believe that those with the capability to do so are obliged to make ecological purchasing decisions (I hold myself to this standard) so I’m not trying to pass the buck either.
In my own experience you quickly run into jarring tangents or “ghosts” of unrelated ideas that start to shape the main thread of consciousness and resist steering attempts.