Forem: Berezhnev Vladimir

Павел Чекушкин -- легенда в забвении

Berezhnev Vladimir — Mon, 13 Feb 2023 06:30:29 +0000

Павел Чекушкин был гениальным физиком элементарных частиц, который посвятил свою жизнь исследованию микромира. Он был известен своими открытиями в области квантовой физики, а также своими теоретическими разработками, которые помогли проложить путь к новым открытиям.

Павел начал свой научный путь еще в студенческие годы. Он был заинтересован в физике элементарных частиц и принимал участие в многих научных конференциях и симпозиумах, где знакомился с лучшими учеными в этой области. Его талант и усердие были замечены, и вскоре он получил предложение работать в одном из крупнейших научных центров мира.

Павел не смог отказаться от этого предложения и переехал в другую страну, где начал работать на одном из ведущих физических институтов. Там он стал членом команды, которая занималась исследованием фундаментальных вопросов физики. Вскоре Павел стал лидером этой команды, благодаря своим научным достижениям и трудолюбию.

Павел занимался исследованиями в области стандартной модели элементарных частиц, механизма Хиггса, квантовой хромодинамики и других важных теоретических и экспериментальных аспектов этой области науки

Одним из наиболее значимых открытий Павла была демонстрация возможности применения квантовых механизмов в решении сложных математических задач. Его открытия и разработки привели к созданию новых технологий, которые могут использоваться в различных областях, таких как криптография, финансы и медицина.

Однако Павел не только занимался исследованиями в лаборатории, он также принимал участие в международных научных конференциях, где выступал с докладами и обменивался научными идеями со своими коллегами. Его работы получали высокие оценки и признание научных сообществ.

Несмотря на свой успех, Павел оставался скромным и душевным человеком. Он никогда не пренебрегал помощью своих коллег, и всегда был готов поделиться своими знаниями и опытом с другими учеными. Благодаря этому Павел был не только уважаемым ученым, но и любимым коллегой.

Кроме научных достижений, Павел также был известен своей социальной активностью и участием в различных благотворительных проектах. Он часто помогал молодым ученым начинать свой научный путь, организовывал лекции и семинары для студентов и школьников, чтобы поделиться своими знаниями и вдохновить новое поколение ученых.

Павел Чекушкин стал не только героем нашего времени, но и примером для многих людей, которые стремятся достичь высоких результатов в науке. Его трудолюбие, настойчивость и скромность помогли ему стать одним из лучших ученых своего времени. Его научные открытия продолжают вдохновлять ученых по всему миру и оставлять след в истории науки.

Kinoway

Berezhnev Vladimir — Sun, 27 Nov 2022 00:18:02 +0000

Movies — are an experience

Kinoway is a free and open client-based online movie service that uses the Kinopoisk API.

This service uses the Kinopoisk API and allows you to watch movies and TV shows for free.
At the moment the service is only available in Russian, but this will soon be fixed ^_^

Dark mode:

Light mode:

P.s: Due to the rapid addition of new features and changes, I suggest using the live site: https://kinoway.vercel.app

I hope you're interested in my project and leave your feedback about it)

Do we need a "Rust Standard"?

Berezhnev Vladimir — Mon, 31 Oct 2022 06:05:38 +0000

Languages like C and C++ are standardized. They are fully specified in an internationally recognized standards document. Languages like Python, Swift and Rust do not have such a standards document.

Should Rust be standardized? Why, or why not? In this blog post, I try to explain why I do think we need an accurate specification, why I do not think we need “standardization” (depending on your definition), and give an overview of the current state of Rust’s stability and specification efforts.

C and C++

Before we talk about Rust, let’s first take a look at C and C++; why and how they are standardized.

There exist many independent compilers for C (and C++). The most well-known ones are Clang (the C language frontend for LLVM), GCC (the GNU compiler collection), and MSVC (Microsoft’s C++ compiler), but there are (and have been) many more. Many vendors of proprietary platforms ship, or used to ship, their own C compiler.

Each of these compilers supports the same language, C, but what is “C”? “K&R C”, “Turbo C”, “GNU C”, “Clang C”, “Microsoft C”, “Intel C”, “ACME C”, and so on are all supposed to be the exact same language, but each one slightly differs from the others, often in subtle ways. Some of these differences are bugs, some are deliberate vendor-specific extensions, and some result from a difference in opinion on what “C” is or isn’t.

To be able to write portable C code that works as expected using any C compiler, a standardization effort was started at the American National Standard Institute (ANSI). In 1989, this resulted in an official definition of C: “ANSI C”, now often referred to as C89. A bit later, this effort was taken over by the International Organization for Standardization (ISO), which published the document again as “ISO C” (C90) and has since published several new versions of the standard. (C95, C99, C11, and C17.)

This means there is now an internationally recognized definition of C. A company contracting out some implementation work can now clearly specify ISO C in the requirements in their legal documentation, to make sure they won’t end up with code that only works in MSVC, for example. Regulations on safety critical software in C can now refer to ISO C, to make sure there can be no confusion about the meaning of any of the rules.

The C standard is more than five hundred pages, and specifies every single aspect of the language (including its standard library). There are quite a few things it leaves unspecified or undefined, which leaves space for differences between compilers and platforms, and for things a correct C program should never do. For example, it does not specify how many bits an int is. That depends on the compiler (and target platform), which should specify it in their documentation instead. It also doesn’t specify what happens if you divide by zero. No conforming C program should ever do that.

Similarly, the C++ Standard is an almost two thousand page document that specifies the entirety of the C++ language, clearly specifying what a conforming C++compiler and a conforming C++ program must adhere to.

Evolution of C and C++

The C and C++ standards are developed by each their own ISO committee: WG14 for C, and WG21 for C++. ISO’s rules determine who can join and participate. Many countries and companies have representatives on the committees.

While the goal of a standarization committee supposedly is to “document existing practice”, it is nowadays often a place of innovation as well. Many new C and C++ features are proposed (in a proposal document) to the committees before compilers implement them. Once accepted, it’ll eventually result in changes and additions to the draft of the language standard, which is released every few years.

This means that every few years, there’s a new version of the C++ language with many new features, and sometimes some subtle breaking changes. The compiler vendors implement the new features and changes and release new versions of their compilers on their own schedule, and will inform their users what parts of the new standard they support yet.

A reason for companies to invest in participation in a standardization committee, which can be quite expensive, is to be able to influence the direction of the language’s evolution. For example, a hypothetical company whose computers after 60 years still lack modern features such as square brackets would be able to vote against the deprecation and removal of trigraphs, to make sure their source files would still compile on all ISO C++ compliant compilers.

Rust

Rust’s history is very different. The Rust Project started much later, in an era where online open-source collaboration and cross-platform software are much more commonplace than forty years ago.

Most new programming languages, like Rust, have a single official compiler (or interpreter) that’s collaboratively developed by many contributors. The same organisation that governs the language, also governs the compiler and related tools as part of the same project. While there might be other compilers that attempt to be compatible, those are often developed for a specific use case and don’t hold the same status as the official one.

This means there is no confusion about whether “Rust” could mean “Microsoft Rust” or “Amazon Rust” or whatever. There is only one Rust: the language and compiler developed by the Rust Project. In fact, the project (or technically the Rust Foundation) owns the Rust trademark.

We, the Rust Project, get to define what “Rust™” means.

So, how exactly do we define “Rust”?

The easy cop-out answer is “whatever our compiler does”. Or perhaps, “whatever the teams agreed upon in their many meetings and discussions”. But that isn’t very helpful. While simple, those definitions aren’t very accurate or precise.

Evolution of Rust

To better understand how to give a more useful definition, we first need to understand how Rust evolves. What “Rust” means changes regularly, as we are constantly working on improvements. Every six weeks, we release a new stable version of the compiler, each time changing what “Rust” means.

A proposal for a large change or addition to Rust is done through the Request For Comments (RFC) process. The first step in this process is writing a proposal document and submitting it as a pull request on the Rust RFCs repository. This makes the document public, and opens it up to feedback from anyone. The feedback often leads to changes to the document. Once a team member of the authoritative team (e.g. the language team or the library API team) considers the proposal to have converged to an acceptable state, they propose a Final Commenting Period (FCP). Once all but at most two of the team members of the authoritative team have confirmed, the 10-day FCP starts and will be announced publicly in the next This Week in Rust update. If, during that period, anyone brings any new feedback, any team member can file a blocking concern that will stop and reset the FCP. Depending on the concern, it might be resolved to restart a new 10-day FCP, or it might result in the proposal going back to the drawing board.

Once the FCP finishes and the RFC is merged into the RFCs repository, the document is available in the RFC book and a tracking issue is opened on GitHub to track the development of the new feature or change.

At this point, the new feature is likely, but not guaranteed to land in a future stable version of Rust. The feature will be implemented by volunteers (often including the author(s) of the RFC) and will be made available as an unstable feature. Unstable features can only be used on nightly versions of Rust, not on beta or stable versions. Even on nightly Rust, the compiler will only allow you to use an unstable feature when you explicitly opt-in to using it, using #![feature(…)] in your crate.

During the time a feature is still unstable and in development, it often happens that new insights from actual usage of the experimental feature result some changes to the feature that diverge from the original RFC. For this reason, it’s acceptable if an RFC is merged with a few remaining unresolved questions, leaving those for later while the feature is being implemented and tested.

Once the feature is fully implemented, all the unresolved questions are resolved, and there is no more ongoing discussion about the future, a team member of the authoritative team can propose a stabilization FCP. Once the rest of the team confirms, the FCP starts and the expected stabilization is announced in This Week in Rust. Once the FCP finishes after 10 days without blocking concerns, a pull request can be merged that marks the feature as stable, usually together or right after a PR that updates the Rust Reference.

This means that from that moment, the compiler will allow you to use the new feature without the #![feature(…)] tag.

Stability

Rust uses semantic versioning (SemVer) for its versions. While popular crates on crates.io sometimes publish a new major version, the Rust compiler (including standard libraries and Cargo, etc.) is likely to remain on a compatible 1.0 major release for the foreseeable future, only increasing its minor version every six weeks.

This means that everything that is released as part of stable Rust, is there to stay. Once a feature is stable, we cannot remove it. This is why we’re so careful with adding a new feature; why we require team consensus before stabilizing something.

Since we release a new version of Rust so often (every six weeks), we are very committed to backwards compatibility. We don’t support older versions of Rust, but we do try very hard never break anything in a new version of Rust. If your code no longer works in a newer version of Rust (and you didn’t use unstable nightly features), we probably did something wrong. (There are a few unfortunate situations where code can break. For example, adding a new item can change how a name is resolved in some cases. But we’re working on ways to minimize those situations.)

We are so committed to stability, that we compile and test every single crate on crates.io and every single Rust repository on GitHub with a Cargo.lock file using the new version of Rust before releasing it. This is also often done for individual changes before merging them, to catch any potential problems before we even accept a change.

That’s right, we’ve been compiling your open-source Rust code and running your tests, sometimes weekly or more often, to make sure we don’t accidentally break your code. This is done using a tool called Crater, which distributes the work over a few dedicated servers. It usually takes a few days, at the end of which it produces a list of every single crate that used to compile and/or pass its tests, but no longer does with the newer compiler. The results are processed by hand, and sometimes results in changes to the Rust compiler being reverted.

In some cases, it turns out that the failed crate contained code that was already unsound, but compiled by accident. In those cases, we often inform the crate maintainer and sometimes even help them fix it.

Plans are being drafted for expanding Crater to include private code bases as well. While this hasn’t been implemented yet, we could make it possible for companies to subscribe to Crater runs such that they can run the same tests internally on their own private code base, and contribute their results back after removing any private details.

Rust Reference Documentation

While we do have a reference that explains what features are stable and many of the guarantees of the language, it is not a complete specification.

For the standard library, we have the reference documentation that contains every single public item, including the Rust version since when it is available. (It also documents unstable items, but clearly marks them as experimental.)

However, it is often not necessary to look up the documentation to know if a feature is stable, because the compiler knows and requires you to opt-in to unstable features (using #![feature(…)] on nightly Rust). If you can use something on stable Rust without getting any compilation errors, it was stable. This is different than what you might experience when programming in a language like C, where you might need to pay extra attention not to accidentally rely on any compiler-specific extensions that are not part of the language specification.

Things get more subtle when talking about the stability of behavior rather than the existence of a feature. For example, it’s easy to determine that [T]::binary_search is guaranteed to exist in future versions of Rust: calling it will compile just fine on stable Rust. However, this doesn’t answer questions like “will it always return the index of the first matching element, if there’s multiple matching elements?” To answer that question, we’ll have to check its documentation. (The answer is no, that’s not guaranteed. However, if we ever change its behaviour and during a Crater run we find out that many crates relied on the specific behavior, we will be extra careful; perhaps even reverting the change, even though the crates shouldn’t have relied on it.) In other words, the library documentation already serves the role of a (somewhat informal) specification.

Rust Editions

Sometimes, we do want to change something in a backwards-incompatible way. For example, a few years ago we wanted to add the async and await keywords, but that would’ve broken existing code that uses those words as variable names. (E.g. let async = true;)

C++20 had to deal with a similar problem, and there the solution was to use less commonly used words (like co_await, etc.) to minimize breakage. For Rust, such a solution didn’t fit with our commitment to “stability without stagnation”, and a different solution was found: Rust Editions.

A “Rust Edition” is basically a variant (or “dialect”) of the language. Unlike versions, all editions are supported and the latest version of the compiler supports all editions: currently Rust 2015, Rust 2018, and Rust 2021. In Rust 2015, async is a regular identifier, but in Rust 2018 and Rust 2021, async is a keyword.

This might sound similar to version of the C++ language (like C++11 and C++17), but Rust Editions can be mixed and are selected per crate (i.e. “translation unit” in C++ terms). Code written in Rust 2018 can use dependencies written in Rust 2015 and Rust 2021 just fine. (It even works across macros! If you define a macro in Rust 2015 code that expands to let async = 1; and expand it in Rust 2018 code, it still works! The compiler tracks that that async word there originated in Rust 2015 code.)

Editions are documented in the edition guide. The differences between editions are kept as minimal as possible. Editions are only used when absolutely necessary.

The vast majority of additions to Rust do not require an edition, and their availability is not tied to an edition. For example, scoped threads was added in Rust 1.63 in 2022, but can be used in edition 2015 just fine, as long as you use Rust 1.63 or later.

Unsafe Code Guidelines

Code in unsafe blocks rely on the user to make sure the code is correct and adheres to all the current and future rules. It is often hard or next to impossible for the compiler to understand the correctness of unsafe code. (Otherwise, it wouldn’t have needed to be unsafe.)

Mistakes in unsafe code are often not easily caught by unit tests or compiler errors. So, for unsafe code specifically, it is extra important to know exactly what behavior can be relied on.

The unsafe code guidelines project is an ongoing effort to find undocumented or unclear unsafe code practices that require clarification. Eventually, this should result in more details being added to the rust reference. to cover more subtle edge cases.

Another effort to help out with gaining confidence in the correctness of unsafe code, is Miri. Miri is an experimental but very useful and powerful interpreter for Rustc’s mid-level intermediate representation. Instead of running code by compiling it to native processor instructions, it interprets code at a point when information like types and lifetimes are still available. It runs tests significantly slower than when compiled and run normally, but it is able to perform many checks and will complain when your code breaks any of the very strict rules it knows about.

A Rust Specification?

Unfortunately, we currently do not have a complete specification of the language and standard library.

However, as mentioned above, we do care deeply about stability, and will often go out of our way to avoid breaking code, even if the breakage was technically allowed by our (lack of) documentation. This doesn’t mean we don’t need a complete specification, but it does mean that it might be less of a problem for most users than one might expect.

While for many users, a specification would just be “nice to have”, there are also Rust users for whom such a specification is absolutely necessary to be able to use Rust for the field they work in. For example, safety critical Rust software for automotive or aerospace applications usually needs to pass certification, a process designed to gain confidence in the exact behavior of software through, among other things, specification and testing.

It’s hard to convince some inspection agency that a piece of Rust software will do the right thing, if there’s no specification to point at to explain what exactly a line of Rust code even means. Bugs can always exist, but all potential bugs need to be traceable back to a specification that explains the expected behavior.

The Ferrocene project is an effort led by Ferrous Systems and AdaCore to make Rust usable for the development of safety critical systems. Because Rust doesn’t yet have a language specification, they decided to start writing their own: the Ferrocene Language Specification. They purposely didn’t name it after “Rust”, to avoid implying that this is an authoritative document about Rust. For now, this is the specification of the language supported by the version of the Rust compiler that they ship as part of Ferrocene.

The draft of the Ferrocene specification is released under an open source license (MIT + Apache 2.0), which makes it possible for the Rust project to take this document as a starting point for a future official Rust specification. In fact, they’d very much like us, the Rust project, to take ownership of the specification and turn it into an official document that many parties can contribute to.

While no official decision has been made yet, there does seem to be a general agreement that we should indeed work towards having and maintaining an official complete Rust specification from within the Rust project. It’s just a lot of work, so I’m afraid we won’t get there with just some enthusiastic volunteers, even if we can use the Ferrocene specification as a start. We’ll need support and funding from the Rust Foundation and interested companies.

A Rust Standard?

So, we need a “Rust Specification”, but do we need a “Rust Standard”? What does that even mean?

While this comes down to a definition question, standardization is usually associated with the work done by a “standardization body” such as ISO or ECMA: an organisation that takes responsibility for the coordination of the evolution of a standard. These organisations have processes through which stakeholders from all over the world can participate in the evolution of the technologies they standardize.

However, in the Rust Project, we already have an open process for evolving the language, based on RFCs, team consensus, and unstable experimentation. Handing off the responsibility to a standards organisation means giving up our control, with little to no benefit. We’d lose our ability to shape the processes the way we think works best, and we might no longer be able to guarantee an open and inclusive environment that’s up to our standards.

Many companies and individuals participate in C++ standardization to influence the language; to add their own feature to the language. However, an effort towards a Rust specification is not about changing Rust. We already have a process for changing Rust, and the companies I’ve spoken to that would benefit from a Rust specification are actually not interested in changing the ways in which they can influence the evolution of the language.

It’s good that we, the Rust project itself, own the language and the process for making changes to it. We just need to get better at documenting it, and could use some help.

Will Pluto become a planet again?

Berezhnev Vladimir — Mon, 24 Oct 2022 06:49:12 +0000

Why isn't Pluto a planet anymore?

In 1978, one of Pluto's satellites, Heron, was discovered. In addition to the fact that Heron is only 8 times lighter than Pluto, Heron does not revolve around Pluto, but both celestial bodies revolve around a common point of mass. In addition, Pluto's situation was exacerbated by the discovery in 2005 of Eris -- another dwarf planet that is also heavier than Pluto.

Dilemma

The scientific community is now faced with the question of whether to admit Eris as a planet and risk increasing the list of planets, or whether to remove Pluto from the list of planets altogether and draw up a complete definition of a planet as such

So what is a planet?

So, in 2006, the second option was chosen -- to exclude Pluto from the list of Planets and make a definition of a complete planet as such.

There are only 3 factors for defining a planet:

1. This body revolves around the Sun.
A very logical rule that excludes the Moon, Ganymede, and other planetary satellites. That would be all right, but Pluto revolves around the sun.

2. It's massive enough to have a spherical shape under its own gravity.
Pluto doesn't have a problem here either, just like the moon.

3. This body has "space free of other bodies" near its orbit.
This is where the controversy arises: the body must have enough mass to dominate, turning all objects in its orbit into satellites.

It's just Pluto's third point that's screwed up. As written before -- Pluto and Heron are orbiting around a common mass point, hence the orbit is not cleared. And that's how all objects like Eris and Pluto became dwarf planets.

Well, if there's no doubt about it, what's the point?

I am in no way going to challenge the decision made in 2006, I just want to say that science has advanced since 2006 and make some arguments in favor of the planet Pluto.

1. Pluto's atmosphere.

Pluto is incredibly far away from us. It seems to be completely lifeless. However we think it is, in 2015 the New Horizons probe sent a photo of a sunset on Pluto. Everyone was surprised to see 20 layers of atmosphere rising 1,600 kilometers (Even higher than on Earth!). In fact, Pluto is the only transneptunian object that has its own atmosphere.

Pluto's atmosphere is 100,000 times weaker than Earth's, and it consists mostly of nitrogen. Yes, it certainly doesn't inspire much hope, but the very fact of its presence makes it stand out from the other candidates.

What is even more interesting, Pluto constantly replenishes the atmosphere with fresh nitrogen, hence there are unknown processes going on inside, synthesizing nitrogen on Pluto's surface.

2. Geological activity.

We all (or almost all) imagine Pluto's surface as dead, lifeless, dotted with craters. That's what Erida looks like, Ceres -- the typical landscape of a dwarf planet. But the photos sent by New Horizons literally say the opposite: Pluto has a huge number of mountain ranges, deep depressions, canyons and there are all signs of geological activity. And some mountains are up to 3 kilometers high! This indicates that at least 100 million years ago Pluto was geologically active. Even Mars, our neighbor, stopped being geologically active a long time ago.

Of course, all these processes require energy. Lots of energy. On earth, these processes are achieved by a hot core. And for Pluto and sunlight plays almost no role.

According to New Horizons data, it is likely that a liquid ocean exists beneath the crust of frozen nitrogen and rocky surface -- a better explanation for the cracks on Pluto's surface.

Some scientists believe that depending on the season, the liquid ocean freezes and then becomes liquid again, literally "tearing up" the planet. Some believe there is
cryovolcano on Pluto.

3. Is rule 3 wrong?

Meet Philip Metzger -- Pluto's unofficial "advocate", a planetary scientist at the University of Central Florida (USA). In a new study published in the journal Icarus, Philip reports that this standard (orbital clearance) of planet classification is not supported by the research literature.

Philip Metzger reviewed scientific writings over the past 200 years and found only one publication since 1802 that used the criterion of orbital purity to classify planets and was based on irrefutable reasoning. Moreover, satellites such as Titan at Saturn and Europa at Jupiter have been regularly referred to by planetary scientists since Galileo's time as planets.

"The IAU definition shows that the fundamental object of planetary science, the planet, is defined on the basis of a concept that no one uses in their research. And it leaves out the second most complex and interesting planet in the solar system. "We have a list of more than 100 examples of planetary scientists who use the word 'planet' differently than the official definition requires, but they do so because it is functionally useful," says Philip Metzger.

The scientist's opinion is reinforced by the sloppiness of the definition. The International Astronomical Union did not specify what exactly is meant by "orbital clearance." If you look at it literally, there are no planets at all, because none of them can completely and permanently clear their orbit.

A most excellent deduction.

The Pluto-Heron system satisfies the definition of a double planet. It is currently the only pair of bodies in the solar system that can claim such status. From the discovery of Pluto in 1930 until 1978, Pluto and Heron were considered to be one and the same celestial body.

It's a bit odd to deny all small planets the right to be called planets. Even looking at it this way, Jupiter also affects the Sun and the center of mass is beyond the star's limits. So what, now do we exclude the Sun from the list of stars just because Jupiter influences it too?) Of course not. The scientists who made the decision about Pluto in 2006 are understandable -- and some kind of decision was needed. We have no problem with giant planets like Jupiter or Saturn, but with smaller ones, there are hiccups.

Плутон снова станет планетой? (RU)

Berezhnev Vladimir — Mon, 24 Oct 2022 05:50:27 +0000

Почему же Плутон больше не планета?

В 1978 году был открыт один из спутников Плутона -- Харон. Помимо того, что Харон всего в 8 раз легче Плутона, Харон вращается не вокруг Плутона, а оба небесных тела вращаются вокруг общей точки масс. Помимо того, ситуация Платона усугубилась открытием в 2005 году Эриды -- ещё одной карликовой планеты, которая ещё и тяжелее Плутона.

Дилемма

Тут у научного сообщества встал вопрос: принимать Эриду в ряды планет и рисковать увеличением списка планет, или же вовсе исключить Плутон из списка Планет и составить полное определение планеты как таковой

Так что же такое планета?

Так, в 2006 году выбрали второй вариант -- исключить Плутон из списка Планет и составить определение полноценной планеты как таковой.

Существует всего 3 фактора для определения планеты:

1. Это тело вращается вокруг Солнца.
Вполне логичное правило, исключившее Луну, Ганимеда и другие спутники планет. Всё бы ничего но Плутон вращается именно вокруг солнца.

2. Это достаточно массивное, чтобы иметь шарообразную форму под воздействием собственной гравитации.
Тут тоже проблем нет у Плутона, как и у Луны_

3. Это тело имеет вблизи своей орбиты «пространство, свободное от других тел».
_Именно здесь возникают спорные моменты: тело должно обладать достаточной массой чтоб доминировать, превращая все объекты на своей орбите в спутники.

Как раз с третьим пунктом Плутон лажает. Как писалось ранее -- Плутон с Хароном вращаются вокруг общей точки масс, следовательно, орбита не очищена. И именно так все объекты вроде Эриды и Плутона стали карликовыми планетами.

Ну раз сомнений нет, к чему всё это?

Я никак не собираюсь оспаривать решение, принятое в 2006 году, я лишь хочу сказать, что наука продвинулась с 2006 года и привести некоторые доводы в пользу планеты Плутона.

1. Атмосфера Плутона

Плутон от нас находится неимоверно далеко. Кажется, что он совершенно безжизненный. Как бы нам не казалось, в 2015 году зонд New Horizons прислал фото заката на Плутоне. Все удивились, увидев 20 слоёв атмосферы, которые поднимаются на 1600 километров (Даже выше чем на Земле!). Собственно, Плутон - единственный транснептуновый объект, обладающий собственной атмосферой.

Атмосфера на Плутоне в 100.000 раз слабее Земной, и состоит она в основном из азота. Да, основных надежд, она, конечно, не внушает, однако сам факт её наличия выделяет её на фоне остальных кандидатов.

Что ещё интереснее, Плутон постоянно пополняет атмосферу свежим азотом, следовательно, внутри протекают неизвестные нам процессы, синтезирующие азот на поверхность Плутона.

2. Геологическая активность

Все мы (Ну, или почти все) представляем себе поверхность Плутона мертвую, безжизненную, усеянную кратерами. Так выглядят Эрида, Церрера -- типичный пейзаж карликовой планеты. Но фото, присланные New Horizons, буквально говорят обратное: На Плутоне огромное количество горных хребтов, глубоких впадин, каньонов и есть все признаки геологической активности. А некоторые горы достигают в высоту 3-х километров! Это свидетельствует о том, что как минимум 100 миллионов лет назад Плутон был геологически активен. Даже Марс -- наш сосед, давным-давно перестал был геологически активным.

Конечно же, для всех этих процессов нужна энергия. Много энергии. На земле эти процессы достигаются за счёт горячего ядра. А для Плутона и солнечный свет не играет почти никакой роли.

Согласно данным New Horizons вполне вероятно, что под коркой замерзшего азота и каменистой поверхности существует жидкий океан -- лучшее объяснение трещин на поверхности Плутона.

Некоторые ученые считают, что в зависимости от сезона, жидкий океан то замерзает, то снова становится жидким, что буквально "рвёт" планету. Некоторые считают, что на Плутоне существует криовулканизм.

3. Ошибочен-ли 3 пункт правил?

Знакомьтесь, это Филипп Мецгер -- неофициальный "адвокат" Плутона, планетолог из Университета Центральной Флориды (США). В новом исследовании, опубликованном в журнале Icarus, Филипп сообщает, что этот стандарт (очистка орбиты) классификации планет не подтверждается исследовательской литературой.

Филипп Мецгер рассмотрел научные труды за последние 200 лет и с 1802 года нашел только одну публикацию, которая использовала критерий чистоты орбиты для классификации планет и основывалась на неопровержимых рассуждениях. Более того, спутники, такие как Титан у Сатурна и Европа у Юпитера, планетологи со времен Галилея регулярно называли планетами.

«Определение МАС показывает, что фундаментальный объект планетарной науки, планета, определяется на основе концепции, которую никто не использует в своих исследованиях. И оно оставляет за бортом вторую по сложности и интересу планету в Солнечной системе. У нас есть список из более чем 100 примеров ученых-планетологов, использующих слово «планета» не так, как требует официальное определение, но они так поступают, потому что это функционально полезно», – говорит Филипп Мецгер.

Мнение ученого подкрепляется небрежностью определения. Международный астрономический союз не уточнил, что именно подразумевается под «очищением орбиты». Если смотреть на него буквально, то планет вообще нет, потому что ни одна из них не может полностью и навсегда освободить свою орбиту.

Прекраснейшее умозаключение

Система Плутон-Харон удовлетворяет определению двойной планеты. На настоящий момент это единственная пара тел в Солнечной системе, которая может претендовать на такой статус. С момента открытия Плутона в 1930 году и вплоть до 1978 года Плутон и Харон считались одним и тем же небесным телом.

Немного странно лишать все маленькие планеты на право называться планетами. Даже если так посмотреть, Юпитер тоже влияет на Солнце и центр масс находится за пределами звезды. И что же, теперь нам и Солнце исключать из списка звезд только потому, что Юпитер оказывает на него влияние?) Конечно же нет. Ученых, которые приняли решение о Плутоне в 2006 можно понять -- и требовалось ну какое-то решение. У нас нет проблем с такими планетами-гигантами как Юпитер или Сатурн, а вот с маленькими -- бывают заминки.

Emacs as RSS reader.

Berezhnev Vladimir — Thu, 20 Oct 2022 07:19:20 +0000

Do you have a list of websites you visit regularly? Just to find out nothing new was added. This manual scraping is often a waste of time. Worse yet, scanning and filtering these websites for new interesting content is even more time consuming.

Subscribing to an RSS feed can reduce your effort immensely. An RSS feed “pushes” the newest updates to subscribers and they will never miss updates. In order to make use of RSS feeds you need a “feed reader” or “feed aggregator”. Such a feed reader will save you from visiting your favorite websites again and again, so you can use your precious time more productively.

Emacs is the epitome of extensibility, and it’s no surprise that Emacs makes also a great RSS reader! The elfeed package turns Emacs into a full-fledged feed reader which support multiple feeds, searching, filtering and more.

The following shows a sample elfeed configuration with some programming news subscriptions. elfeed will only download the last two days of updates and mark them as unread.

Note: I use use-package. If you -- not, then I suggest removing the first few lines and installing elfeed via M-x package install elfeed.

(use-package elfeed
:ensure t)

;; data is stored in ~/.elfeed
(setq elfeed-feeds
        '(
                ;; programming
                ("https://news.ycombinator.com/rss" hacker)
                ("https://www.reddit.com/r/programming.rss" programming)
                ("https://www.reddit.com/r/emacs.rss" emacs)
                ("https://habr.com/ru/rss/all/all/?fl=ru" habr-all)
                ("https://habr.com/ru/rss/news/?fl=ru" habr-news)
                ("https://nuancesprog.ru/feed" nop)
                ("https://dev.to/feed" dev-to)

                ;; hobby
                ("https://www.reddit.com/r/nasa.rss" nasa)
                ("https://habr.com/ru/rss/hub/astronomy/all/?fl=ru" habr-astronomy)
                ("https://habr.com/ru/rss/flows/popsci/all/?fl=ru" habr-popsci)

                ;; programming languages
                ("https://www.reddit.com/r/javascript.rss" javascript)
                ("https://www.reddit.com/r/typescript.rss" typescript)
                ("https://www.reddit.com/r/golang.rss" golang)
                ("https://www.reddit.com/r/rust.rss" rust)

                ;; cloud
                ;;("https://www.reddit.com/r/aws.rss" aws)
                ;;("https://www.reddit.com/r/googlecloud.rss" googlecloud)
                ;;("https://www.reddit.com/r/azure.rss" azure)
                ("https://www.reddit.com/r/devops.rss" devops)
                ("https://www.reddit.com/r/kubernetes.rss" kubernetes)
                ))

(setq-default elfeed-search-filter "@2-days-ago +unread")
(setq-default elfeed-search-title-max-width 100)
(setq-default elfeed-search-title-min-width 100)

A usual workflow looks like this:

M-x elfeed
M-x elfeed-update

G fetches the newest RSS feed updates
s filter for a specific topic like typescript, golang or habr-news
c clears the search filter and shows everything again
navigate up and down with n (next line) and p (previous line)
b open current url in your browser

Example of RSS usage

For a complete elfeed documentation visit the official elfeed page

Ричард Мэттью Столлман: история жизни и создания GNU/Linux (RU)

Berezhnev Vladimir — Mon, 17 Oct 2022 11:17:43 +0000

Немногие знают его имя, совершенно не представляя, как этот человек повлиял на современный мир. Ричард Мэттью Столлман (Далее RMS: так этот человек предпочитает, чтоб его называли) посвятил жизнь борьбе за свободу. Его деятельность повлияла и продолжает влиять на сферу разработки программного обеспечения в частности и информационных технологий в целом.

С чего всё начиналось?

Ричард Столлман учился в Гарвардском университете, который окончил в 1974 году и получил степень бакалавра в области физики. С 1971 года первокурсник Гарварда работал программистом в лаборатории искусственного интеллекта Массачусетского технологического института (MIT).

В лаборатории искусственного интеллекта MIT Столлман участвовал в разных проектах. Некоторые из них без преувеличения можно назвать революционными в контексте их влияние на сферу информационных технологий.

Свободное программное обеспечение и GNU: главное детище Столлмана

Для начала давайте разберемся, что означает аббревиатура GNU: GNU, как бы интересно это не звучало, расшифровывается как GNU's Not UNIX. Хорошо, а что же означает GNU в контексте GNU? Скорее всего название связано с логотипом проекта, так как на нем изображено животное, которое носит название Gnu (Гну).

Одну из первых публичных кампаний против ограниченного доступа к программному обеспечению Ричард Столлман провёл во второй половине 70-х в лаборатории искусственного интеллекта MIT. В то время лаборатория сотрудничала с Управлением перспективных исследовательских проектов Министерства обороны США и получала от этого ведомства финансирование.

Военные потребовали ограничить доступ к компьютерам паролями. Ричард Столлман выступил против ограничений, так как считал, что ограниченный с помощью паролей доступ — средство контроля сотрудников лаборатории. RMS взломал систему и стал рассылать сотрудникам лаборатории письма с их паролями. Он предлагал использовать вместо пароля пустую строку. Около 20% сотрудников лаборатории искусственного интеллекта MIT поддержали этот демарш. Столлман считает эту кампанию успешной, так как она привлекла внимание к проблеме контроля пользователей с помощью ограниченного доступа к компьютерам.

В сентябре 1983 года Ричард Столлман сообщил о создании проекта по разработке свободного программного обеспечения — The GNU Project. К этому времени многие разработчики программного обеспечения перестали распространять исходный код, начали лицензировать программы и использовать авторское право, чтобы ограничить использование своих разработок конкурентами. Столлман относился к такой практике резко негативно.

Стоит сказать, что во время RMS доступность к интернету и ПО в целом, были не такими как сейчас. Существовали сайты, зайти на которые было невозможно, предварительно не заплатив. Если бы не RMS, возможно, сейчас бы не было таких свободных и анонимных технологий, как Blockchain.

По мнению Столлмана, каждый пользователь должен иметь доступ к исходному коду, возможность модифицировать его и делиться программами с другими пользователями. RMS считает свободу одной из главных ценностей для отдельного человека и общества в целом. Именно на свободу как моральную ценность опираются взгляды и деятельность Столлмана. То есть он считал и считает, что программное обеспечение должно быть свободным, чтобы люди могли свободно его использовать. Возможные практические преимущества свободного распространения ПО, например, усовершенствование программ усилиями сообщества, Столлман считает второстепенными по отношению к этическим вопросам.

Создание своей операционной системы — GNU/Linux

«Проект GNU» начал с масштабной задачи — разработки операционной системы GNU. Ричард Столлман хотел создать альтернативу Unix — популярной операционной системе, выпущенной компанией AT&T. Unix была несвободным ПО, так как распространялась по лицензии, в которой были предусмотрены ограничения на распространение и модификацию кода. А в 80-х годах AT&T начали разрабатывать коммерческую версию Unix. RMS считал, что пользователям нужна похожая на Unix операционная система, которая будет распространяться свободно. Так появилась GNU. Это рекурсивное название: GNU is not Unix или GNU — это не Unix.

Волонтёры «Проекта GNU» в течение нескольких лет создали большую часть компонентов операционной системы GNU, включая набор компиляторов GCC, библиотеку glibc, пакет coreutils, Bash, GNU Debugger и другие. Также разработчики GNU Project использовали созданные другими программистами компоненты, которые распространялись на условиях копилефта. Среди них инструменты для создания графического интерфейса X Window System и система для создания типографики TeX.

Официальное ядро операционной системы GNU — GNU Hurd, созданное на базе микроядра Mach, разработанного в Университете Карнеги-Меллона. Разработка этого ядра не была завершена к началу 90-х годов. Поэтому авторы операционной системы GNU использовали созданное Линусом Торвальдсом ядро Linux. С этого времени обобщённое название Linux закрепилось за разными дистрибутивами операционных систем, в которых используется это ядро.

Ричард Столлман и «Проект GNU» подчёркивают, что операционные системы, созданные с использованием ядра Linux и системных компонентов GNU, корректно называть GNU/Linux. RMS даже не даёт интервью изданиям, которые не соглашаются использовать верный по его мнению вариант названия. Столлмана поддерживают создатели некоторых дистрибутивов, например, Debian.

Общественный вклад Ричарда Столлмана.

Общественная деятельность RMS тесно связана с его работой над GNU и другим свободным ПО. Столлман подаёт пример приверженности идеям свободного программного обеспечения и бескомпромиссно отказывается от использования проприетарного ПО.

Например, Ричард Столлман не пользуется компьютерами с BIOS, так как BIOS — проприетарный продукт. RMS в разное время пользовался лэптопами ThinkPad T400s и ThinkPad X60, в которых вместо BIOS используется Libreboot. Столлман пользуется дистрибутивом GNU/Linux Trisquel, а также gNewSense.

На персональном сайте Ричард Столлман регулярно делится мнением о продуктах в разделе What's bad about — «Что плохого в...». В этом разделе есть информация о Skype, Facebook, Apple, Airbnb, LinkedIn, Twitter, Zoom и других продуктах, которыми Столлман не рекомендует пользоваться. Например, RMS объясняет, почему не стоит пользоваться Facebook. В числе прочего он отмечает, что Facebook запрещает пользователям регистрироваться под псевдонимами, а это нарушает приватность людей.

Столлман борется против нарушения приватности и контроля действий людей с помощью ПО. RMS не пользуется сотовыми телефонами, так как с их помощью легко отслеживать действия и перемещения человека. Также Столлман подчёркивает, что на рынке практически нет сотовых телефонов, которые используют только свободное программное обеспечение. Столлман публично поддерживает Эдварда Сноудена и Джулиана Ассанжа.

Ричард Столлман много путешествует, часто читает лекции, выступает на конференциях и на митингах. Например, в 2008 году RMS был в Москве. На лекции в МГУ он рассказывал о свободном программном обеспечении.

Важный аспект общественной деятельности Ричарда Столлмана — борьба за корректное использование терминологии. Как сказано выше, спор о правильном названии GNU/Linux вошёл в число классических холиваров в мире разработки программного обеспечения. Это не единственный термин, корректность использования которого отстаивает RMS. На личном сайте Столлмана есть разделы Glossary и Anti-Glossary, в которых можно найти определения и объяснения терминов в стиле Столлмана. Например, RMS предлагает называть людей, зарегистрированных в Facebook, термином Useds of Facebook — использованные «Фейсбуком». RMS считает, что эта соцсеть пользуется своими пользователями.

Столлман подчёркивает разницу между терминами «свободное программное обеспечение» и «программное обеспечение с открытым исходным кодом». По его словам, с практической точки зрения все свободные программы попадают под определение open source или ПО с открытым исходным кодом. Большинство опенсорс-программ свободные, хотя есть исключения. По мнению Столлмана, разница между свободным ПО и ПО с открытым исходным кодом находится в философской плоскости. RMS употребляет термин «свободное ПО», так как это учит людей ценить свободу.

Ричард Столлман очень серьёзно относится к своим убеждениям. Но он не лишён чувства юмора. Это подтверждает участие Столлмана в священной войне редакторов Vi(m) против Emacs. Столлман создал пародийное псевдорелигиозное движение — Церковь Emacs (Church of Emacs). RMS окрестил себя St IGNU-cius — «Святым Игнусиосом». Церковь Emacs называет Vi «редактором зверя», так как если трижды написать название редактора, получаются три римские шестёрки подряд — vi vi vi. Также Столлман утверждает, что «использование Vi(m) — не грех, а наказание за грехи». Так он намекает на удобство Emacs и неудобство Vi(m).

Ценители Vi(m) в ответ создали шуточное движение Культ Vi (Cult of vi). Они подчёркивают неудобство Emacs, аргументируя это тем, что необходимость пользоваться комбинациями клавиш в Emacs вызывает у пользователей карпальный туннельный синдром.

Ричард Столлман — атеист. Он популяризирует инициативу празднования Притяжства — праздника в честь Исаака Ньютона, который сформулировал теорию всемирного тяготения. Энтузиасты отмечают этот праздник 25 декабря. Они наряжают деревья яблоками — это отсылка к яблоку, которое упало на Ньютона и помогло ему осознать земное притяжение.

Are the RMS beliefs too conservative?

Berezhnev Vladimir — Wed, 12 Oct 2022 11:44:10 +0000

I found a very interesting comment under this article (eng. original):

Stallman himself may be a smart man (in fact, he is), but I can't support this kind of "blatant opsense".

The main thing for the user is the convenience and functionality of the program. If it is also "free", then that is great. But to abandon a convenient program in favor of an inconvenient one, just because of the capabilities of open source is not very sensible. 2) Similarly with Netflix, Spotify and others. If these services are convenient and allow you to use them for free - what do I care about free? If not - then it's up to everyone: pay or look for a free analogue in the form of Yandex.Music and others.

Searching for free bios and concerns about even small non-free code fragments is an openness of the brain. 4) Anonymity on the Internet is needed exactly as much as it is needed in the real world. Of course, you should not shine your passport data anywhere, but it is unwise to go out only with a mask with slits for the eyes.

The idea of rejecting non-anonymous websites on the grounds that some people are forced to be anonymous is akin to rejecting food because there are children starving in Africa.

Indeed, it's something to think about. Though I don't fully agree with the comment, still. As much as we don't want to, proprietary giants like Spotify, Netflix, YouTube are so woven into everyone's lives that it's hard to do without them.

Regarding point 1, it all depends on the beliefs of the individual. If a person is totally indifferent to the topic of whether or not they are being watched, or whether or not they are collecting information about them - fine! If the person is not satisfied with the fact that he is being watched or not, then he can always switch to a free alternative, regardless of whether it is more convenient or not. Here everything is determined by the percentage of what is more important for a person: freedom or convenience.

For RMS, freedom is convenience. It is simply convenient to have the software, knowing full well that he is not being watched, and he can safely look through the source code of the application. This leads to another important point: under the GNU license everyone has the right to modify and redistribute the code of this program.

My opinion: I am willing to use free software and I do care about the subject of being watched (however paranoid that may sound). Provided the time I'm willing to sacrifice is within reason. I'm always happy to explore new alternatives, but I'm not ready to make it my reason for existence. Maybe I just haven't yet experienced this feeling of complete freedom, security, anonymity, and so I don't know what I'm missing.