cultural reviewer and dabbler in stylistic premonitions

  • 1 Post
  • 16 Comments
Joined 3 years ago
cake
Cake day: January 17th, 2022

help-circle
  • for example, on a linux distro, we could modify the desktop environment and make it waaaaay lighter by getting rid of jpg or png icons and just using pure svg on it.

    this has largely happened; if you’re on a dpkg-based distro try running this command:

    dpkg -S svg | grep svg$ | sort

    …and you’ll see that your distro includes thousands of SVG files :)

    explanation of that pipeline:
    • dpkg -S svg - this searches for files installed by the package manager which contain “svg” in their path
    • grep svg$ - this filters the output to only show paths which end with svg; that is, the actual svg files. the argument to grep is a regular expression, where $ means “end of line”. you can invert the match (to see the paths dpkg -S svg found which only contain “svg” in the middle of the path) by writing grep -v svg$ instead.
    • the sort command does what it says on the tin, and makes the output easier to read

    you can run man dpkg, man grep, and man sort to read more about each of these commands.


  • No, SVG files are not HTML.

    Please change this post title (currently “today i learned: svg files are literally just html code”), to avoid spreading this incorrect factoid!

    I suggest you change it to “today i learned: svg files are just text in an html-like language” or something like that.

    SVG is a dialect of XML.

    XML and HTML have many similarities, because they both are descendants of SGML. But, as others have noted in this thread, HTML is also not XML. (Except for when it’s XHTML…)

    Like HTML, SVG also can use CSS, and, in some environments (eg, in browsers, but not in Inkscape) also JavaScript. But, the styles you can specify with CSS in SVG are quite different than those you can specify with CSS in HTML.

    Lastly, you can embed SVG in HTML and it will work in (modern) browsers. You cannot embed HTML in SVG, however.




  • Note: for readers who aren’t aware, the notation ^X means hold down the ctrl key and type x (without shift).

    ctrl-a though ctrl-z will send ASCII characters 1 through 26, which are called control characters (because they’re for controling things, and also because you can type them by holding down the control key).

    ^D is the EOF character.

    $ stty -a | grep eof
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    $ man stty |grep -A1 eof |head -n2
           eof CHAR
                  CHAR will send an end of file (terminate the input)
    

    Nope, Chuck Testa: there is no EOF character. Or, one could also say there is an EOF character, but which character it is can be configured on a per-tty basis, and by default it is configured to be ^D - which (since “D” is the fourth letter of the alphabet) is ASCII character 4, which (as you can see in man ascii) is called EOT or “end of transmission”.

    What that stty output means is that ^D is the character specified to trigger eof. That means this character is intercepted (by the kernel’s tty driver) and, instead of sending the character to the process reading standard input, the tty “will send an end of file (terminate the input)”.

    By default eof is ^D (EOT), a control character, but it can be set to any character.

    For instance: run stty eof x and now, in that terminal, “x” (by itself, without the control key) will be the EOF character and will behave exactly as ^D did before. (The rest of this comment assumes you are still in a normal default terminal where you have not done that.)

    But “send an end of file” does not mean sending EOT or any other character to the reading process: as the blog post explains, it actually (counterintuitively) means flushing the buffer - meaning, causing the read syscall to return with whatever is in the buffer currently.

    It is confusing that this functionality is called eof, and the stty man page description of it is even more so, given that it (really!) does actually flush the contents of the buffer to read - even if the line buffer is not empty, in which case it is not actually indicating end-of-file!

    You can confirm this is happening by running cat and typing a few characters and then hitting ^D, and then typing more, and hitting ^D again. (Each time you flush the buffer, cat will immediately echo the latest characters that had been buffered, even though you have not hit enter yet.)

    Or, you can pipe cat into pv and see that ^D also causes pv to receive the buffer contents prior to hitting enter.

    I guess unix calls this eof because this function is most often used to flush an empty buffer, which is how you “send an end of file” to the reader.

    The empty-read-means-EOF semantics are documented, among other places, in the man page for the read() syscall (man read):

    RETURN VALUE
          On success, the number of bytes read is returned (zero indicates end of
          file), and the file position is advanced by this number.
    

    If you want to send an actual ^D (EOT) character through to the process reading standard input, you can escape it using the confusingly-named lnext function, which by default is bound to the ^V control character (aka SYN, “synchronous idle”, ASCII character 22):

    $ man stty|grep lnext -A1
           * lnext CHAR
                  CHAR will enter the next character quoted
    $ stty -a|grep lnext
    werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
    

    Try it: you can type echo " and then ctrl-V and ctrl-D and then "|xxd (and then enter) and you will see that this is sending ascii character 4.

    You can also send it with echo -e '\x04'. Note that the EOT character does not terminate bash:

    $ echo -e '\x04\necho see?'|xxd
    00000000: 040a 6563 686f 2073 6565 3f0a            ..echo see?.
    $ echo -e '\x04\necho see?'|bash
    bash: line 1: $'\004': command not found
    see?
    

    As you can see, it instead interprets it as a command.

    (Control characters are perfectly cromulent filenames btw...)
    $ echo -e '#!/bin/bash\necho lmao' > ~/.local/bin/$(echo -en '\x04')
    $ chmod +x ~/.local/bin/$(echo -en '\x04')
    $ echo -e '\x04\necho see?'|bash
    lmao
    see?
    


  • Arthur Besse@lemmy.mlMtoLinux@lemmy.mlroot (or sudo) access delay instead of password
    link
    fedilink
    English
    arrow-up
    24
    arrow-down
    1
    ·
    edit-2
    2 days ago

    sure. first, configure sudo to be passwordless, or perhaps just to stay unlocked for longer (it’s easy to find instructions for how to do that).

    then, put this in your ~/.bashrc:

    alias sudo='echo -n "are you sure? "; for i in $(seq 5); do echo -n "$((6 - $i)) "; sleep 1; done && echo && /usr/bin/sudo '

    Now “sudo” will give you a 5 second countdown (during which you can hit ctrl-c if you change your mind) before running whatever command you ask it to.




  • Nice post, but your title is misleading: the blog post is actually titled “Supply Chain Attacks on Linux distributions - Overview” - the word “attacks” as used here is a synonym for “vulnerabilities”. It is not completely clear from their title if this is going to be a post about vulnerabilities being discovered, or about them actually being exploited maliciously, but the latter is at least not strongly implied.

    This lemmy post however is titled (currently, hopefully OP will retitle it after this comment) “Supply Chain Attack found in Fedora’s Pagure and openSUSE’s Open Build Service”. edit: @OP thanks for changing the title!

    Adding the word “found” (and making “Attack” singular) changes the meaning: this title strongly implies that a malicious party has actually been detected performing a supply chain attack for real - which is not what this post is saying at all. (It does actually discuss some previous real-world attacks first, but it is not about finding those; the new findings in this post are vulnerabilities which were never attacked for real.)

    I recommend using the original post title (minus its “Overview” suffix) or keeping your more verbose title but changing the word “Attack” to “Vulnerabilities” to make it clearer.

    TLDR: These security researchers went looking for supply chain vulnerabilities, and found several bugs in two different systems. After responsibly disclosing them, they did these (very nice and accessible, btw - i recommend reading them) writeups about two of the bugs. The two they wrote up are similar in that they both involve going from being able to inject command line arguments, to being able to write to a file, to being able to execute arbitrary code (in a context which would allow attackers to perform supply chain attacks on any software distributed via the targeted infrastructure).



  • Fuck this project, but… their source code can be free and open source even if they distribute binaries which aren’t. (Which they can do if they own the copyright, and/or if it is under a permissive non-copyleft FOSS license.)

    And if the source code is actually FOSS, and many people actually want to use it, someone else will distribute FOSS binaries without this stupid EULA. So, this BS is still much better than a non-FOSS license like FUTO’s.


  • Arthur Besse@lemmy.mltoOpen Source@lemmy.mlOpen source maintenance fee
    link
    fedilink
    English
    arrow-up
    22
    arrow-down
    1
    ·
    edit-2
    3 days ago

    I immediately knew this was going to be from Microsoft users, and yeah… of course, it is.

    Binaries distributed under this EULA do not meet the free software definition or open source definition.

    However, unlike most attempts to dilute the concept of open source, since the EULA is explicitly scoped to binaries and says it is meant to be applied to projects with source code that is released under an OSI-approved license, I think the source code of projects using this do still meet the open source definition (as long as the code is actually under such a license). Anyone/everyone should still be free to fork any project using this, and to distribute free binaries which are not under this EULA.

    This EULA obviously cannot be applied to projects using a copyleft license, unless all contributors to it have dual-licensed their contributions to allow (at least) the entity that is distributing non-free binaries under this EULA to do so.

    I think it is extremely short-sighted to tell non-paying “consumers” of an open source project that their bug reports are not welcome. People who pay for support obviously get to heavily influence which bugs get priority, but to tell non-paying users that they shouldn’t even report bugs is implicitly communicating that 2nd and 3rd party collaboration on fixing bugs is not expected or desired.

    A lot of Microsoft-oriented developers still don’t understand the free software movement, and have been trying to twist it into something they can comprehend since it started four decades ago. This is the latest iteration of that; at least this time they aren’t suggesting that people license their source code under non-free licenses.



  • I didn’t know red hat was working for the US government. Can you tell me in what way?

    tldr: https://www.redhat.com/en/solutions/public-sector/dod

    see also: https://web.archive.org/web/20240530005438/https://www.redhat.com/en/resources/israeli-defense-forces-case-study

    Various documents in (what wikipedia now calls) the “2010s global surveillance disclosures” showed that many components of NSA (and other Five Eyes partners) infrastructure is run on RedHat Enterprise Linux.

    According to a 2008 study by the Office of the Director of National Intelligence, private contractors make up 29% of the workforce in the United States Intelligence Community and cost the equivalent of 49% of their personnel budgets. RedHat is part of that industry.

    It’s often illuminating to search a company’s job listings for words like “clearance”. There are currently only eight listings for that query at RedHat but sometimes they have many more. Here (archive) is a current one. Here is another one archived last year.

    Here is the text, in case the archive site loses it

    Consulting Architect, TS/SCI + Polygraph Clearance Required (Fort Meade)

    remote type Remote

    locations Remote US MD

    time type Full time

    posted on Posted 30+ Days Ago

    job requisition id R-038935

    About The Job

    Red Hat’s Public Sector Consulting team is looking for a Consulting Architect with a solid background in Linux, container platforms, IT Automation, virtualization technologies and an active TS/SCI + Polygraph security clearance to join us remotely in Maryland. In this role, you will help Intelligence Community customers design and operate core infrastructure that can scale to the demands of the modern digital marketplace. You’ll work with customers in small teams to build, test, and iterate over innovative application prototypes attached to real business value. You’ll use a variety of modern application development practices, along with emerging technologies from open source communities to get it done. As a Consulting Architect, you will help us become the defining technology company of the 21st century built on open source principles. You’ll also help us to fulfill our vision by guiding the strategic success of our customers using Red Hat’s solutions by building the industry’s best team of open source developers and partnering with our customers to build the premium software systems of tomorrow.

    This position requires frequent on-site work at Fort Meade and an active TS/SCI + Polygraph security clearance.

    What You Will Do

    • Deliver successful discovery, analysis, and design workshops for teams of technical and non-technical backgrounds that shape the customer use cases and architecture design decisions
    • Scope delivery projects and guide customers through successful pilot and production deployments
    • Oversee the design, creation, and delivery of content that enables the broader Red Hat teams to sell (presales), service (consulting), and support our cloud solutions at scale
    • Work closely with product business, product engineering, consulting, technical support, and sales teams to ensure excellent customer experience with Red Hat’s offerings
    • Contribute to the development of repeatable methodologies and tools designed to scale Red Hat’s services capabilities, promote repeatable customer engagements, and lower delivery risk
    • Demonstrate expertise in cloud and DevOps communities by producing outstanding whitepapers and webinars, code contributions to relevant projects, and speeches at industry-leading conferences
    • Work with customers on the writing of business justifications if needed
    • Work with the open source community to engineer labs-based software solutions designed to further accelerate our customers’ success at Labs
    • Become a trusted adviser to our customers, helping them achieve business success in an ever-changing technology landscape

    What You Will Bring

    • Active Top Secret w/ SCI security clearance + Polygraph
    • Broad knowledge of Red Hat OpenShift, Red Hat Ansible Automation Platform, and Red Hat Enterprise Linux
    • Broad and deep technical experience with virtualization, container, and cloud technologies
    • Solid Linux system administration skills; Red Hat Certified Engineer (RHCE)-level Linux skills or better; certifications are a plus but not required
    • Experience with cloud technologies, especially Red Hat OpenStack Platform, Amazon Web Services (AWS), Microsoft Azure, and Google Compute Platform (GCP)
    • Extensive technical experience with virtualization, especially Red Hat Virtualization, VMware vSphere, Microsoft Hyper-V, and Citrix XenServer; VMware Certified Professional certification is a plus
    • Solid debugging, troubleshooting, and general problem-solving skills
    • Great customer service skills and desire to make users successful
    • Positive attitude, ability to work as part of a team, and excellent written and verbal communication skills
    • Deep understanding of working with DISA, FISMA, NIST, and STIG security guidelines and how to adhere to them
    • Experience working within the US Department of Defense (DoD) and US Intelligence Community (IC)
    • Ability to make on-site customer visits

    The following are considered a plus:

    • Practical experience with Red Hat Satellite or similar systems-management technologies
    • Experience with Red Hat Ansible Automation Platform or other IT automation and configuration management tools like Puppet or Chef
    • Experience with datacenter automation tools and processes
    • System administration or datacenter architecture experience
    • Windows system administration
    • Ruby, Python, or PowerShell programming experience
    • Ability to study and learn quickly and put new topics into practice
    • Passion for open source software

    #LI-REMOTE #LI-AL2

    The salary range for this position is $138,350.00 - $228,310.00. Actual offer will be based on your qualifications.

    Pay Transparency

    Red Hat determines compensation based on several factors including but not limited to job location, experience, applicable skills and training, external market value, and internal pay equity. Annual salary is one component of Red Hat’s compensation package. This position may also be eligible for bonus, commission, and/or equity. For positions with Remote-US locations, the actual salary range for the position may differ based on location but will be commensurate with job duties and relevant work experience.

    About Red Hat

    Red Hat is the world’s leading provider of enterprise open source software solutions, using a community-powered approach to deliver high-performing Linux, cloud, container, and Kubernetes technologies. Spread across 40+ countries, our associates work flexibly across work environments, from in-office, to office-flex, to fully remote, depending on the requirements of their role. Red Hatters are encouraged to bring their best ideas, no matter their title or tenure. We’re a leader in open source because of our open and inclusive environment. We hire creative, passionate people ready to contribute their ideas, help solve complex problems, and make an impact.

    Benefits

    • Comprehensive medical, dental, and vision coverage
    • Flexible Spending Account - healthcare and dependent care
    • Health Savings Account - high deductible medical plan
    • Retirement 401(k) with employer match
    • Paid time off and holidays
    • Paid parental leave plans for all new parents
    • Leave benefits including disability, paid family medical leave, and paid military leave
    • Additional benefits including employee stock purchase plan, family planning reimbursement, tuition reimbursement, transportation expense account, employee assistance program, and more!

    Note: These benefits are only applicable to full time, permanent associates at Red Hat located in the United States.

    Diversity, Equity & Inclusion at Red Hat Red Hat’s culture is built on the open source principles of transparency, collaboration, and inclusion, where the best ideas can come from anywhere and anyone. When this is realized, it empowers people from diverse backgrounds, perspectives, and experiences to come together to share ideas, challenge the status quo, and drive innovation. Our aspiration is that everyone experiences this culture with equal opportunity and access, and that all voices are not only heard but also celebrated. We hope you will join our celebration, and we welcome and encourage applicants from all the beautiful dimensions of diversity that compose our global village.

    Equal Opportunity Policy (EEO) Red Hat is proud to be an equal opportunity workplace and an affirmative action employer. We review applications for employment without regard to their race, color, religion, sex, sexual orientation, gender identity, national origin, ancestry, citizenship, age, veteran status, genetic information, physical or mental disability, medical condition, marital status, or any other basis prohibited by law.

    Red Hat does not seek or accept unsolicited resumes or CVs from recruitment agencies. We are not responsible for, and will not pay, any fees, commissions, or any other payment related to unsolicited resumes or CVs except as required in a written contract between Red Hat and the recruitment agency or party requesting payment of a fee.

    Red Hat supports individuals with disabilities and provides reasonable accommodations to job applicants. If you need assistance completing our online job application, email application-assistance@redhat.com. General inquiries, such as those regarding the status of a job application, will not receive a reply.



  • Clickbait. The VP Engineering for Ubuntu made a post that he was looking into using the Rust utils for Ubuntu and has been daily driving them and encouraged others to try

    It’s by no means certain this will be done.

    Here is that post. It isn’t certain to happen, but he doesn’t only say that he is daily driving them. He says his goal is to make them the default in 25.10:

    My immediate goal is to make uutils’ coreutils implementation the default in Ubuntu 25.10, and subsequently in our next Long Term Support (LTS) release, Ubuntu 26.04 LTS, if the conditions are right.