Adobe Flash is Officially Dead After 25 Years With Content Blocked Starting Today

MacRumors : Mac News and Rumors Adobe Flash is Officially Dead After 25 Years With Content Blocked Starting Today

A few weeks ago, Adobe dropped support for Flash Player and continued to strongly recommend that all users immediately uninstall the browser plugin for security reasons. And starting today, Adobe has gone one step further and blocked Flash content entirely.


When a user attempts to load a Flash game or content in a browser such as Chrome, the content now fails to load and instead displays a small banner that leads to the Flash end-of-life page on Adobe’s website. While this day has long been coming, with many browsers disabling Flash by default years ago, it is officially the end of a 25-year era for Flash, first introduced by Macromedia in 1996 and acquired by Adobe in 2005.

« Since Adobe will no longer be supporting Flash Player after December 31, 2020 and Adobe will block Flash content from running in Flash Player beginning January 12, 2021, Adobe strongly recommends all users immediately uninstall Flash Player to help protect their systems, » the page reads. Adobe has instructions for uninstalling Flash on Mac, but note that Apple removed support for Flash outright in Safari 14 last year.

Adobe first announced its plans to discontinue Flash in 2017. « Open standards such as HTML5, WebGL, and WebAssembly have continually matured over the years and serve as viable alternatives for Flash content, » the company explained.

Adobe does not intend to issue Flash Player updates or security patches any longer, so it is recommended that users uninstall the plugin.

Over the years, Flash had an infamous reputation due to numerous security vulnerabilities that exposed Mac and PC users to malware and other risks, forcing vendors like Microsoft and Apple to work tirelessly to keep up with security fixes.

Apple’s co-founder and former CEO Steve Jobs offered his « Thoughts on Flash » in a 2010 open letter, criticizing Adobe’s software for its poor reliability, security, and performance. Jobs also said that Apple « cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers. »

Flash’s discontinuation should not heavily impact most users since many popular browsers have already moved away from the plugin. Additionally, iPhone and iPad users are not affected by the change, as iOS and iPadOS have never supported Flash.

This article, « Adobe Flash is Officially Dead After 25 Years With Content Blocked Starting Today » first appeared on MacRumors.com

Discuss this article in our forums

https://www.macrumors.com/2021/01/12/adobe-flash-era-is-officially-over/

Sent with Reeder

Envoyé de mon iPhone

JavaScript Turns 25

Slashdot JavaScript Turns 25

The programming language JavaScript emerged 25 years ago and has grown to become one of the most important pieces of the web and browser applications we use today. From a report: JavaScript is the go-to language for front-end development and has spawned Microsoft’s Typescript, a superset of JavaScript with a stronger optional type system for developers that compiles to JavaScript when run in the browser. Both JavaScript and TypeScript conform to ECMAScript, the standard for JavaScript and node.js, the runtime for running applications outside of the browser thanks to Google’s powerful V8 JavaScript engine. JavaScript’s impact on the web cannot be understated. Tech giants have thrown their weight behind the language. Besides Google’s V8, there are open source projects like React from Facebook and Angular from Google, which help spread web applications across smartphones and desktop. After Netscape and Sun Microsystems — where Java was hatched in May 1995 by James Gosling — announced JavaScript in December 1995, Microsoft promoted Visual Basic (VB) as a standard for creating web applications using VB Script for its Internet Explorer browser. Oracle would go on to buy Sun Microsystems in 2008 largely to get its hands on Java and its huge development ecosystem. The press release about its launch from 25 years ago.

Read more of this story at Slashdot.

http://rss.slashdot.org/~r/Slashdot/slashdot/~3/iPT779Vd5JQ/javascript-turns-25

Sent with Reeder

Envoyé de mon iPhone

Reading Manpages Like a Pro (2018)

Hacker News Reading Manpages Like a Pro (2018)

Tags: programming, workflow

Preword

I often reference the manpages when giving a development presentation or talk, but I’ve only recently come to realize how few people are both comfortable with the man interface and adept at discovering information through it.

This post is my attempt to share some of the tricks and techniques I’ve picked up over years of reading manpages.

A Quick Recap

The manpages (short for “manual pages”) are the oldest and longest-running documentation collection on *nix, stemming back to the first edition of the Unix Programmer’s Manual in 1971.

On a modern system, the man command is the most common way to access the manpages:

1  2  3  4  5  6  7  8  
# access the first manpage named "time", which happens to be time(1)  man time # access a specific section's "time", in this case the C time function  man 2 time # attempt to access a nonexistent "time" in section 5  man 5 time  

Because the manpages were originally published on paper, they were (and continue to be) typeset with troff on most systems. Today, the man command (and other manpage readers) invoke troff internally and pipe the output to the user’s pager (like more or less).

In fact, a very simple manpage reader (which only works with section 1) can be implemented with just three commands pipelined together:

1  2  3  4  5  6  7  8  9  
function myman { # `-t` and `-e`: run `tbl` and `eqn` on the input, for tables and equations # `-mandoc`: use a set of troff macros specifically for manpages # `-Tutf8`: output UTF-8 text rather than PostScript gunzip < /usr/share/man/man1/"${1}.1.gz" | groff -t -e -mandoc -Tutf8 | less  } myman gcc  myman ls  

Apart from their simplicity and adherence to the UNIX philosophy, man and the manpages serve a number of important roles:

  • They provide a categorization: section 1 is for system commands, 2 for system calls, 3 for library functions, and so forth. This categorization is followed both by the system itself (which populates several of the sections) and by programs installed by the user or package manager.

  • They provide offline documentation: man doesn’t require an internet connection, and can provide much of the documentation that an internet search would yield.

  • They offer canonical information: searching for a command or function online might tell you whether it exists, but won’t tell you the flags, arguments, or behavior specific to your system. For example, man ls will tell you whether your system’s ls is BSD or GNU (and the differences therebetween). The manpages (on Linux) will also tell you which feature macros you’ll need to define in a C program in order to use a function (or a variant of a function).

So, let’s move on to some techniques.

Colorized manpages

One of the simplest things you can do to enhance the readability of manpages within man is to colorize the pager’s output:

A colorized version of `man gcc`

In less, this is accomplished by setting the LESS_TERMCAP_* environment variables to your preferred ANSI color codes. Here are the variables you can set:

1  2  3  4  5  6  7  
LESS_TERMCAP_mb # blinking mode (not common in manpages)  LESS_TERMCAP_md # double-bright mode (used for boldface)  LESS_TERMCAP_me # exit/reset all modes  LESS_TERMCAP_so # enter standout mode (used by the less statusbar and search results)  LESS_TERMCAP_se # exit standout mode  LESS_TERMCAP_us # enter underline mode (used for underlined text)  LESS_TERMCAP_ue # exit underline mode  

You may be able to set others corresponding to the termcap capability names, but the variables above should cover all of your manpage needs.

By way of example, here is the bash function I use to colorize my manpages:

1  2  3  4  5  6  7  8  9  10  11  
man() { env \ LESS_TERMCAP_mb="$(printf "\e[1;31m")" \ LESS_TERMCAP_md="$(printf "\e[1;31m")" \ LESS_TERMCAP_me="$(printf "\e[0m")" \ LESS_TERMCAP_se="$(printf "\e[0m")" \ LESS_TERMCAP_so="$(printf "\e[1;44;33m")" \ LESS_TERMCAP_ue="$(printf "\e[0m")" \ LESS_TERMCAP_us="$(printf "\e[1;32m")" \ man "${@}"  }  

Note that you don’t need to use escape sequences as above — tput will work just fine.

Other sections

I mentioned some of the big sections above: 1 for system commands, 2 for system calls, and so on.

90% of man lookups will be in those three, but there are a few lesser-known sections that can also be useful:

  • man 4 – Special files and devices

    On Linux, section 4 is used to document special files, usually representing some aspect of the machine or its peripherals. For example, man 4 mem will tell you how to use the /dev/mem, /dev/kmem, and /dev/port files to read from and write to the system’s main memory.

  • man 5 – Configuration files and formats

    You probably know the /etc/shadow file, but do you know how its format is specified? man 5 shadow will tell you that. Similarly, man 5 deb describes the .deb package format, and man 5 ppm lists the spec for PPM images.

  • man Np – POSIX pages

    These pages come in handy for contrasting POSIX behavior with the system’s behavior.

    Some examples:

    1  2  3  4  5  6  7  8  
     # compare the system ls (on Linux, GNU) to the POSIX ls behavior man 1 ls man 1p ls # compare the read syscall to the POSIX read function # note the categorization: POSIX read is a function, not a syscall! man 2 read man 3p read  

Searching and navigating

Like colorization, searching is more of a general less feature than one specific to man. That being said, less’s searching and navigating features can make browsing the manpages a much faster and more pleasant experience.

Searches in less can be forwards or backwards, using the / and ? commands respectively. The search syntax is mostly POSIX ERE, but with some additions (man less has the details!).

For example, to find the first instance of “x86” in man gcc (watch the bottom of the screen for the search prompt):

Observe that instances of the search term are highlighted with the standout colors from before.

Once a search term is entered, its results can be navigated via the n and N commands, which move forwards and backwards in the results list respectively. For example, going through all of the results for “Windows”:

When the last result has been jumped to, the statusbar changes to “Pattern not found”. Once that happens, as in the video above, previous results can be returned to by hitting N.

Even this can be simplified: the & command can be used to display only lines that match the given pattern. For example, retrieving every line that contains either “ARM” or “ABI”:

The effect is more dramatic when searching for the definition of a flag (in this case -D):

These commands are just the tip of the iceberg — less supports searching multiple files at once, jumping around scopes (opening and closing parentheses, braces, brackets), and marking the current location for later return. Each of these is documented on the help screen, which you can get to in any less session via the h command:

Wrapup

Before picking up these tricks (especially searching), the manpages were an item of last resort for me: I would search the internet or ask a friend, with mixed results. I had no real idea how to use less, and would just clumsily page around until I found what I was looking for. More often than not, I would give up entirely.

At the end of the day, the manpages (and the man interface) are not perfect — there’s no hyperlinking or real cross-referencing, and the entire corpus is written in a 45+ year old typesetting language designed for physical output, not display in a virtual terminal.

That being said, they’re a fantastic initial resource for pretty much anything concerning your system — they remain up-to-date (unlike blogs and articles), they’re accurate and concise, and they’re very UNIX-y (text files and pipelines!).

Addendum

This post was discussed on HN; a response by ‘djeiasbsbo includes some additionally useful tricks and advice.

https://blog.yossarian.net/2018/01/22/Reading-Manpages-Like-a-Pro

Sent with Reeder

Envoyé de mon iPhone