• 0 Posts
  • 73 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle
  • I was already a dev in a small IT consultancy by the end of the decade, and having ended up as “one of the guys you go to for web-based interfaces”, I did my bit pushing Linux as a solution, though I still had to use IIS on one or two projects (even had to use Oracle Web Application Server once), mainly because clients trusted Microsoft (basically any large software vendor, such as Microsoft, IBM or Oracle) but did not yet trust Linux.

    That’s why I noticed the difference that Red Hat with their Enterprise version and Support Plans did on the acceptability of Linux.



  • CRT monitors internally use an electron gun which just fires electrons at the phosporous screen (from, the back, obviously, and the whole assembly is one big vacuum chamber with the phosporous screen at the front and the electron gun at the back) using magnets to twist the eletcron stream left/right and up/down.

    In practice the way it was used was to point it to the start of a line were it would start moving to the other side, then after a few clock ticks start sending the line data and then after as many clock ticks as there were points on the line, stop for a few ticks and then swipe it to the start of the next line (and there was a wait period for this too).

    Back in those days, when configuring X you actually configured all this in a text file, low level (literally the clock frequency, total lines, total points per line, empty lines before sending data - top of the screen - and after sending data as well as OFF ticks from start of line before sending data and after sending data) for each resolution you wanted to have.

    All this let you defined your own resolutions and even shift the whole image horizontally or vertically to your hearts content (well, there were limitations on things like the min and max supported clock frequency of the monitor and such). All that freedom also meant that you could exceed the capabilities of the monitor and even break it.


  • In the early 90s all the “cool kids” (for a techie definition of “cool”, i.e. hackers) at my University (a Technical one in Portugal with all the best STEM degrees in the country) used Linux - it was actually a common thing for people to install it in the PCs of our shared computer room.

    Later in that decade it was already normal for it to be used in professional environments for anything serving web pages (static or dynamic) along with Apache: Windows + IIS already had a lower fraction of that Market than Linux + Apache.

    If I remember it correctly in the late 90s RedHat started providing their Enterprise Version with things like Support Contracts - so beloved by the Corporates who wanted guarantees that if their systems broke the supplier would fix them - which did a lot to boost Linux use on the backend for non-Tech but IT heavy industries.

    I would say this was the start of the trend that would ultimately result in Linux dominating on the server-side.


  • If it’s part of the Requirements that the frontend should handle “No results found” differently from “Not authorized”, even if that’s just by showing an icon, then ach list of stuff which might or not be authorized should have a flag signalling that.

    (This is simply data analysis - if certain information is supposed to be shown to the user it should come from somewhere and hence the frontend must get it from somewhere, and the frontend code trying to “deduce it” from data it gets is generally prone to the kind of problem you just got because unless explicitly agreed and documented, sooner or later some deduction done by one team is not going to match what the other team is doing. Generally it’s safer just to explicitly pass that info in a field for that purpose to avoid frontend-backend integration issues).

    Authorization logic is almost always a responsibility of the backend (for various reasons, including proper security practices) and for the frontend it’s generally irrelevant why it’s authorized or not, unless you have to somehow display per-list the reason for a it being authorized or not, which would be a strange UI design IMHO - generally there’s but a flag in the main part of the UI and a separate page/screen with detailed authorization information - if the user really wants to dig down into the “why” - which would be using different API call just to fill in that page/screen.

    So if indeed it is required that the frontend knows if an empty result is due to “Not Authorized” rather than “No results found” (a not uncommon design, though generally a good UI design practice is to simply not even give the user access to listing things the user is not authorized to see rather than let the user chose them and then telling them they’re not authorized to do it, as the latter design is more frustrating for users) that info should be an explicit entry in what comes from the backend.

    The JSON is indeed different in both cases, but if handled correctly it shouldn’t matter.

    That said, IMHO, if all those 3 fields in your example should be present, the backend should be putting a list on all 3 fields even if for some the list is empty, rather than a null in some - it doesn’t matter what the JSON is since even at the Java backend level, a List variable with a “null” is not the same as a List variable with a List of length 0 - null vs empty list is quite a common source of mistakes even within the code of just the one tier, though worse if it ends up in API data.

    Who is wrong or right ultimately depends on the API design having marked those fields as mandatory or optional.


  • That sounds like an error in the specification of the client-server API or an erroneous implementation on the server side for the last version: nothing should be signaled via presence or absence of fields when using JSON exactly because, as I described in my last post, the standard with JSON is that stuff that is not present should be ignore (i.e. it has no meaning at all) for backwards compatibility, which breaks if all of the sudden presence or absence are treated as having meaning.

    Frankly that there isn’t a specific field signalling authorized/not-authorized leads me to believe that whomever has designed that API isn’t exactly experienced at that level of software design: authorization information should be explicit, not implicit, otherwise you end up with people checking for not-in-spec side effects like you did exactly for that reason (i.e. “is the no data being returned because of user not authorized or because there was indeed no data to retunr?”), which is prone to break since not being properly part of the spec means any of the teams working on it might interpret things differently and/or change them at any moment.


  • If I remember it correctly, per the JSON definition when a key is present but not expected it should be ignored.

    The reason for that is to maintain compatibility between versions: it should be possible to add more entries to the data and yet old versions of the software that consumes that data should still continue to operate if all the data they’re designed to handle is still there and still in the correct format.

    Sure, that’s not a problem in the blessed world of web-based frontends where the user browser just pulls the client code from the server so frontend and backend are always in synch, but is a problem for all other kinds of frontend out there where the life-cycle of the client application and the server one are different - good luck getting all your users to update their mobile apps or whatever whenever you want to add functionality (and hence data in client-server comms) to that system.

    (Comms API compatibility is actually one of the big problems in client-server systems development)

    So it sounds like an issue with the way your JavaScript library handles JSON or your own implementation not handling per-spec the presence of data which you don’t use.

    Granted, if the server side dev only makes stuff for your frontend, then he or she needs not be an asshole about it and can be more accomodating. If however that data also has to serve other clients, then I’m afraid you’re the one in the wrong since you’re demanding that the backwards compatibility from the JSON spec itself is not used by anybody else - which as I pointed out is a massive problem when you can’t guarantee that all client apps get updated as soon as the server gets updated - because you couldn’t be arsed to do your implementation correctly.


  • Well, the language is generally different, which is a big barrier to moving (though you can get away with just English in a most countries, but some stuff - often public services - is only in the local language). There is also a cultural element in that people behave and expect slightly different things in different countries, which can be a bit of an adjustment.

    Even bigger than that is that most people aren’t comfortable with big changes and tend to stick to their own country - at the very least the first big move takes a significant amount of courage.

    Then if you have your own house with lots of stuff you have to arrange for the move, which will probably cost you maybe €1500 - €3000 depending on the distance and how much stuff you have.

    And finally, in my experience no country is all good or all shit - they generally have some good things and some bad things. Also, the grass is always greener on the other side of the fence until you move there, were after a while it’s the grass on the other side of the fence that starts looking greener.

    That said, some people - mainly the so-called Digital Nomads - do spend their life moving from country to country whilst working remotelly, which works especially well if you spend different Seasons in different places in Europe (some places are much better in the Summer and others in Winter). This is not new: I’ve met people whose life was working as Scuba Diver instructors in Summer in a country and as Ski Instructors in Winter in a different country.


  • EU countries are allowed to, by Treaty, expel EU citizens who moved there without the means to live there or a job.

    However it’s incredibly rare and there really isn’t any general procedure to do it: each country does it (or not) it’s own way. This tends to be used for people caught sleeping or begging on the streets.

    Further, for countries in the Schengen Area, they don’t even know you’re there unless you register, since you haven’t passed any border controls and thus aren’t in any database as having arrived but not departed.


  • I’ve literally done that inside the EU, though to the UK (back before Brexit) rather than Germany - I flew to London and stayed about a month in a hotel whilst looking for a contract there (I’m a freelancer) and more permanent accommodation.

    Years later I did the same to Germany, though I only stayed 3 months.

    The only requirement is that you either have a job or have the money to pay for the costs of living there (so you can still go without a job, as long as you have the money to pay for a place to stay, food and so on). The reason for the requirement that you can pay your way (either from a job or savings) is because people can’t just move to another EU country to do things like living on the street and begging or living of the local Social Security.

    Some countries also have a requirement that you register after 3 months there (for example, Germany), though it’s not any kind of applying to stay, it’s simply registering as living there. This is usually because there are associated obligations for residents in that country, not just in terms were do you pay tax, but in some countries (for example, Germany and The Netherlands) there are things like mandatory health insurance.

    In practice as an EU citizen, if you have the savings or the kind of job which you can do in 3 month stints or remotely, you absolutely can hop from country to country every 3 months without having to register with anybody (though I’m not sure how taxes would work - I suppose you would pay them in the last country you registered as a Resident).

    If you know the language, if it weren’t for taxes being per country and the rights and duties of Residents being different in different countries (such as the Mandatory Health Insurance for Residents in some countries but not others) hence the requirement to register after 3 months in some countries, the whole thing would be as easy as moving within your own country.


  • The difference between a sociopath and a murdering sociopath is the belief that they will lose nothing and even stand to gain from murder.

    Absolutelly, evil people are to blame from doing evil shit because they chose to do it.

    Other people who protect and support the evil people when they do the evil shit are also to blame because without their support and protection the evil people are a lot less likely to do the evil shit fearing the repercussions.

    In this specific instance, given that the US has been vetoing UN Security Council resolutions to stop Israel and is by far much more powerful than Israel in the World stage, the theory that they’re the “main obstacle to peace in Palestine” makes sense, or in other words, that the murdering sociopath would have to stop murdering due to fear of the consequences if the US stopped supporting it.

    Whilst it seems likely that it is, whether the US really is the “main obstable” or not is something that we would only know for sure after the US stopped supporting Israel.


  • It’s not about debugging tools.

    Different, high level software designs (i.e. architectural designs) which are normally imposed by the game engine, have different probabilities of the developers who are making the code for those to produce bugs, because of lots of factors including things like of how they approach error validation and handling in the engine itself and in which domains does the engine leave the most freedom to coders and which ones does it leave less - some things are pretty safe to leave in the hands of even bad developers, others are not.

    The example of multi-threading in Unity should’ve been clear: put a game engine that doesn’t impose a single thread pattern in front of somebody with little or no experience in multi-threaded programming and you will have a huge rate of bugs (mainly critical race conditions) and as it so happens most developers out there have little or no experience in multi-threaded programming. Yet multi-threading can yield far more performance in modern CPU since they’re all multi-core. For that specific game engine a software architectural choice was made to go with a structure that is not as performance but significantly less likely to lead to a higher bug rate when used by the average coder, probably because Unity targets less experienced coders.

    Good Senior Designers and Technical Architects don’t design the high level structure of the software for themselves as coders, they do it for the kind of coders that are likely to be coding for it.

    Of course the developers themselves also have different capabilities and hence different baseline rates of creating bugs, hence why I said “both”.


  • It’s both.

    The architectural decisions are at the engine level and that stuff has a massive influence on the likelihood of bugs in the code running in that engine.

    For example, traditional Unity (not ECS) runs all game code (so the code provided by those coding the game) in a single thread, which avoids A TON of multi threading bugs (as that’s one of the hardest parts in programming to master) but is very bad for performance in multi-core CPUs. Game programmers can fire up separate threads using the standard libraries of the programming language itself and manage them, but everything in the development framework that’s part of the engine pushes them to use that single-threaded model, so only advanced devs bother and only for very specific things.

    Also the choice of programming language forced by the engine itself has a huge impact in the likelihood of bugs, but since I don’t want to start a Holy War I’m not going to star pointing fingers at specific languages and criticizing them ;)



  • The EULA part is the fishy one, since EULAs are not valid in most of the World - sellers can’t just after the sale force a change of the implicity contract which is the sale itself (worse, refuse to provide access to the functionality of purchased software after the buyer has fullfilled their part of the contract) so EULAs legally mean nothing except (apparently) in a handful of US states.

    The only “licensing conditions” that legally apply here are the ones agreed between seller and buyer before the sale - determining by payment having been given and accepted - not after the sale.

    (Online services get away with TOS changes because it’s an ongowing service rather than a product sale, so the rules are different).




  • Clearly it’s not Infosec!!! ;)

    How do you provide value when that value isn’t needed at the moment?

    Well, that’s why a lot of people want to change things at a political level - the great “pure competition no safety net” neoliberal take on Society results in most of people, whose job is basically a commodity and who don’t have a “unique value proposition”, to be pretty close to slaves in this system because since they are human beings and naturally need food, water and shelter continously but are in an environment where the access to those is controlled by having unusual amounts of the very thing that people selling commoditized services cannot get enough of via their work - money - are squezed into a position where they de facto don’t have any choices, nor do they even have the necessary space to invest in themselves to change into some other job where they might have a “unique value proposition”.

    This situation could be changed if people were guaranteed access to the basic essentials, for example via a Universal Basic Income, since even people doing commoditized work would then have the choice to refuse to “sell” their work if they found the “price” too low or the conditions too bad, which would push the market to improve the jobs offers for those (who are by far the majority if people) plus a lot of those could even chose to improve themselves or their skills, become inventors, or artists, or work in areas with high social value but low “price” because they felt rewarded by it in ways other than money.

    In summary, I think there is no solution within the current paradygm since it makes this problem systemic and any viable solution requires changing at least some things in the paradygm, most noteably the part were the basic required essentials of human beings are used to, at the systemic level, force most people into a no-true-choice neo-slavery.

    The changes we’ve seen to the paradym in the last decade or two are exactly in the opposite direction: the ever more expensive housing and even destruction of the social safety net are forcing even more people to accept bare-minimum near-slavery work just to survive.


  • “Most companies” is not necessarilly the same as “most jobs” since some companies (i.e. large ones) offer many more jobs than others. What counts from how much jobseekers see this kind of practice is “most jobs” so you can have just some companies doing this but if they’re the last ones, that means “most jobs” have this kind of thing. It was probably a needless distinction for me to make in that post.

    I don’t dispute the point that people who are in or seeking employment should not reward bad practices like that, I’m explaining what the previous poster meant: that in the present day economic conditions, most job seekers, whilst not not wanting to reward bad practices do not de facto have the choice to do so because they’re under huge pressure to get a job, any job, as soon as possible.

    Also your theory of hustling your way upinto valued roles is hilarious in light of my almost 3 decades out in the job place - since pretty much the 90s the main way to progress up the career ladder, requires that people change jobs - at least in expert areas, the average salaries of people that stick to one employer are much lower than the average salaries of people who switch jobs periodically because people negotiating a new job whilst still working in the old job, will only ever accept a better job - so their conditions will improve - whilst people in a job and not looking are seldom offered better conditions unless they at least start simulating that they’re working for a better job. I mean, it’s possible to progress without moving jobs especially early in one’s career and under good management, it’s just generally slower and harder than if just hopping jobs.

    I don’t even disagree that being choosy in what jobs you take is how people should behave is they can: I’ve actually successfully done that for all but one of my job transitions, but that’s because I’m a (modesty on the side) well above average senior expert in a high demand area, hence I usually get a lot of offers if I put my CV out and since I’m well paid I have a large pile of savings to rely on during periods between jobs, and thus I can be choosy (and the only time I had to “take a shit job” was exactly early in my career, after the Year-2000 Crash, when after 6 months out of a job and running out of savings I had no other option, and 11 months later after searching for a new job from Day 1 there, I finally found a better job and moved).

    Most people in this World aren’t in such a position and casually suggesting that other people act as you suggest, shows a huge level of ignorance of the economic conditions of most people out there nowadays.

    The kind of wording you use on this suggests you’re in a position of reasonable properity and power in the market place as a job seeker in your area which while good for you is not representative of the median experience of job seekers out there, just like my own situation is not.

    Giving like that “I’m alright Jack” “Everybody should do it just like I can now that I am were I am” suggestions to other people whilst ignoring that most are “Not alright” and not in the same position as you, is at best insensitive and ignorant, at worst insulting, which is probably why you’re getting downvotes.


  • I think that the point is that if those practices are for most employment places in a domain (i.e. the bad practices need not be done by “most companies”, just the largest ones) and people’s main concern is having to eat, they don’t generally have the time to look for the jobs where this shit doesn’t happen and even if they do, they would be competing for a small number of jobs against everybody else also looking for those jobs.

    Or putting things in another way, your idea that somebody can simply “only go for the good jobs” fails at two levels:

    • At an individual level, in the absence of clear upfront information about which jobs are good, people who are between jobs and getting squeezed by high money outflows with no inflows (i.e. the one’s genuinelly concerned about their “need to eat”), can only search for and be demanding about the quality of the jobs they apply for until they get to the point were they just have to take whatever job they can before they run out of savings.
    • At a systemic level, if everybody is going for the few good jobs, there won’t be enough jobs for everybody. Now in an ideal world were people could hold on for a good job as long as it took - i.e. if people weren’t pressed by the need to eat - the bad jobs would dissapear (because they would never find any takers) and all jobs would become good jobs. Once again “people need to eat” means that idea of yours won’t work at a systemic level.

    Your idea to “exclude from consideration companies that do this” only works for some people, not all people, and only those people who have enough savings or low enough money outflows to not have to concede defeat and take one of those not so great jobs because they’re running out of money.

    So the previous poster’s comment of “we need to eat” neatly encapsulates in a simple sentence the reason why your idea won’t work as a general practice or even as an individual practice for most people in the present day society and economy in most countries.