#linustorvalds

Pierwsze README #git napisane przez #linustorvalds w 2005. W następnym commicie który dotyka tego pliku obok zmienił .dircache/index -> .git/index.

https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290#diff-2b7814d3fca2e99e56c51b6ff2aa313ea6e9da6424804240aa8ad891fdfe0900

> GIT - the stupid content tracker
>
> "git" can mean anything, depending on your mood.
>
> - random three-letter combination that is pronounceable, and not
> actually used by any common UNIX command. **The fact that it is a
> mispronounciation of "get" may or may not be relevant.**
> - stupid. contemptible and despicable. simple. Take your pick from the
> dictionary of slang.
> - "global information tracker": you're in a good mood, and it actually
> works for you. Angels sing, and a light suddenly fills the room.
> - "goddamn idiotic truckload of sh*t": when it breaks
>
> This is a stupid (but extremely fast) directory content manager. It
> doesn't do a whole lot, but what it _does_ do is track directory
> contents efficiently.
>
> There are two object abstractions: the "object database", and the
> "current directory cache".
>
> The Object Database (SHA1_FILE_DIRECTORY)
>
> The object database is literally just a content-addressable collection
> of objects. All objects are named by their content, which is
> approximated by the SHA1 hash of the object itself. Objects may refer
> to other objects (by referencing their SHA1 hash), and so you can build
> up a hierarchy of objects.
>
> There are several kinds of objects in the content-addressable collection
> database. They are all in deflated with zlib, and start off with a tag
> of their type, and size information about the data. The SHA1 hash is
> always the hash of the _compressed_ object, not the original one.
>
> In particular, the consistency of an object can always be tested
> independently of the contents or the type of the object: all objects can
> be validated by verifying that (a) their hashes match the content of the
> file and (b) the object successfully inflates to a stream of bytes that
> forms a sequence of + + <ascii decimal
> size> + <byte\\0> + .
>
> BLOB: A "blob" object is nothing but a binary blob of data, and doesn't
> refer to anything else. There is no signature or any other verification
> of the data, so while the object is consistent (it _is_ indexed by its
> sha1 hash, so the data itself is certainly correct), it has absolutely
> no other attributes. No name associations, no permissions. It is
> purely a blob of data (ie normally "file contents").
>
> TREE: The next hierarchical object type is the "tree" object. A tree
> object is a list of permission/name/blob data, sorted by name. In other
> words the tree object is uniquely determined by the set contents, and so
> two separate but identical trees will always share the exact same
> object.
>
> Again, a "tree" object is just a pure data abstraction: it has no
> history, no signatures, no verification of validity, except that the
> contents are again protected by the hash itself. So you can trust the
> contents of a tree, the same way you can trust the contents of a blob,
> but you don't know where those contents _came_ from.
>
> Side note on trees: since a "tree" object is a sorted list of
> "filename+content", you can create a diff between two trees without
> actually having to unpack two trees. Just ignore all common parts, and
> your diff will look right. In other words, you can effectively (and
> efficiently) tell the difference between any two random trees by O(n)
> where "n" is the size of the difference, rather than the size of the
> tree.
>
> Side note 2 on trees: since the name of a "blob" depends entirely and
> exclusively on its contents (ie there are no names or permissions
> involved), you can see trivial renames or permission changes by noticing
> that the blob stayed the same. However, renames with data changes need
> a smarter "diff" implementation.
>
> CHANGESET: The "changeset" object is an object that introduces the
> notion of history into the picture. In contrast to the other objects,
> it doesn't just describe the physical state of a tree, it describes how
> we got there, and why.
>
> A "changeset" is defined by the tree-object that it results in, the
> parent changesets (zero, one or more) that led up to that point, and a
> comment on what happened. Again, a changeset is not trusted per se:
> the contents are well-defined and "safe" due to the cryptographically
> strong signatures at all levels, but there is no reason to believe that
> the tree is "good" or that the merge information makes sense. The
> parents do not have to actually have any relationship with the result,
> for example.
>
> Note on changesets: unlike real SCM's, changesets do not contain rename
> information or file mode chane information. All of that is implicit in
> the trees involved (the result tree, and the result trees of the
> parents), and describing that makes no sense in this idiotic file
> manager.
>
> TRUST: The notion of "trust" is really outside the scope of "git", but
> it's worth noting a few things. First off, since everything is hashed
> with SHA1, you _can_ trust that an object is intact and has not been
> messed with by external sources. So the name of an object uniquely
> identifies a known state - just not a state that you may want to trust.
>
> Furthermore, since the SHA1 signature of a changeset refers to the
> SHA1 signatures of the tree it is associated with and the signatures
> of the parent, a single named changeset specifies uniquely a whole
> set of history, with full contents. You can't later fake any step of
> the way once you have the name of a changeset.
>
> So to introduce some real trust in the system, the only thing you need
> to do is to digitally sign just _one_ special note, which includes the
> name of a top-level changeset. Your digital signature shows others that
> you trust that changeset, and the immutability of the history of
> changesets tells others that they can trust the whole history.
>
> In other words, you can easily validate a whole archive by just sending
> out a single email that tells the people the name (SHA1 hash) of the top
> changeset, and digitally sign that email using something like GPG/PGP.
>
> In particular, you can also have a separate archive of "trust points" or
> tags, which document your (and other peoples) trust. You may, of
> course, archive these "certificates of trust" using "git" itself, but
> it's not something "git" does for you.
>
> Another way of saying the same thing: "git" itself only handles content
> integrity, the trust has to come from outside.
>
> Current Directory Cache (".dircache/index")
>
> The "current directory cache" is a simple binary file, which contains an
> efficient representation of a virtual directory content at some random
> time. It does so by a simple array that associates a set of names,
> dates, permissions and content (aka "blob") objects together. The cache
> is always kept ordered by name, and names are unique at any point in
> time, but the cache has no long-term meaning, and can be partially
> updated at any time.
>
> In particular, the "current directory cache" certainly does not need to
> be consistent with the current directory contents, but it has two very
> important attributes:
>
> (a) it can re-generate the full state it caches (not just the directory
> structure: through the "blob" object it can regenerate the data too)
>
> As a special case, there is a clear and unambiguous one-way mapping
> from a current directory cache to a "tree object", which can be
> efficiently created from just the current directory cache without
> actually looking at any other data. So a directory cache at any
> one time uniquely specifies one and only one "tree" object (but
> has additional data to make it easy to match up that tree object
> with what has happened in the directory)
>
>
> and
>
> (b) it has efficient methods for finding inconsistencies between that
> cached state ("tree object waiting to be instantiated") and the
> current state.
>
> Those are the two ONLY things that the directory cache does. It's a
> cache, and the normal operation is to re-generate it completely from a
> known tree object, or update/compare it with a live tree that is being
> developed. If you blow the directory cache away entirely, you haven't
> lost any information as long as you have the name of the tree that it
> described.
>
> (But directory caches can also have real information in them: in
> particular, they can have the representation of an intermediate tree
> that has not yet been instantiated. So they do have meaning and usage
> outside of caching - in one sense you can think of the current directory
> cache as being the "work in progress" towards a tree commit).

#programowanie

Keynote: Linus Torvalds in Conversation with Dirk Hohndel

https://www.youtube.com/watch?v=YKkEe-PxW10&t=1s

#linustorvalds #linux

https://github.com/torvalds/AudioNoise

Repo Linusa Torvalds w którym pisze, że jest wywajbkodowane.

> Also note that the python visualizer tool has been basically written by vibe-coding. I know more about analog filters -- and that's not saying much -- than I do about python. It started out as my typical "google and do the monkey-see-monkey-do" kind of programming, but then I cut out the middle-man -- me -- and just used Google Antigravity to do the audio sample visualizer.

#linustorvalds

#kartkazkalendarza – 28/12\ \ Tego dnia swoje 56. urodziny świętuje Linus Torvalds – twórca Linuxa, który miał być tylko „projektem hobbystycznym” i „nie być tak dużym i profesjonalnym jak GNU”. Okazało się jednak, że systemy operacyjne oparte o Linuxa stanowią trzecią

https://youtu.be/mfv0V1SxbNA?si=k2ra_JdBufCP_2Yt

#linustorvalds #linustechtips #komputery

Linus i Linus, niedługo bedzie jakis collab na youtubie LinusTechTips

#technologia #linustorvalds #linustechtips

Mój wkład w tworzenie rozwiązań open source I interakcja z twórcą Linuxa. dx

#programowanie #linustorvalds

#linustorvalds #linux

Linus Torvalds Rejects LTTng Upstreaming Request
https://youtu.be/FvEsxg5kW0c

#linux #linustorvalds

#git #linustorvalds #programowanie #github

Two decades of Git: A conversation with creator Linus Torvalds
https://youtu.be/sCr_gb8rdEI

#linustorvalds #programowanie &źródło

https://video.twimg.com/ext_tw_video/1899701917384654848/pu/vid/avc1/720x720/rUBmcDXjU8FRQhEW.mp4?tag=12

#linustorvalds

https://github.com/search?q=repo%3Atorvalds%2Flinux%20fuck&type=code

#linustorvalds #programowanie

Jakiś tydzień temu trafiłem na info, że Linus Torvalds (twórca i główny opiekun #linux )
>w prywatnej korespondencji zapowiedział, że zaakceptuje kod napisany w Rust, nawet pomimo sprzeciwu opiekunów. Zaskakująca zmiana stanowiska może otworzyć drogę do poważnych reform w strukturze jądra systemu, ale jednocześnie rodzi pytania o przyszłość społeczności rozwijającej system.
Było to o tyle dziwne, że
>jeszcze niedawno Torvalds publicznie opowiadał się przeciwko wdrażaniu języka Rust do jądra Linuxa, podkreślając, że system działa znakomicie w C i nie ma potrzeby wprowadzania tak radykalnych zmian. Jego komentarze były surowe i jasno wskazywały na brak akceptacji dla nowego języka w tak kluczowym komponencie oprogramowania.
Jądra systemu napisanego jedynie w języku C bronił jeden z głownych opiekunów Christoph Hellwig:
>Hellwig, nie kryjąc oburzenia, po raz kolejny porównał Rust do "nowotworu", który może zagrozić stabilności jądra Linuxa. Podkreśla, że dodanie wsparcia dla innego języka może prowadzić do chaosu i fragmentacji kodu. „Nieustanna rotacja pomiędzy różnych językami to największy koszmar każdego administratora kodu” – stwierdził Hellwig. 
https://ithardware.pl/aktualnosci/linus_torvalds_rust_i-39142.html

No i dzisiaj pojawia się nowe info:
>Christoph Hellwig, jeden z kluczowych opiekunów jądra systemu, który znany jest ze swojego zdecydowanego sprzeciwu wobec implementacji języka Rust w jądrze Linuksa, zrezygnował z funkcji opiekuna odpowiedzialnego za dma-mapping.
>
>Christoph Hellwig od lat jawnie krytykował wprowadzanie Rusta do kodu jądra Linuksa, nazywając go „rakiem” i podkreślając, że jego obecność rozprzestrzenia się jak „przerzuty” po całym systemie. Hellwig, zagorzały zwolennik języka C, uważał, że to właśnie C zapewnia większą stabilność i bezpieczeństwo kodu. Jego decyzja o rezygnacji z części obowiązków przyszła niespełna tydzień po tym, jak ujawnił treść prywatnej korespondencji z Torvaldsem, w której twórca Linuxa wyraził swoje zaskakujące poparcie dla języka Rust.
Co będzie dalej z Christophem?
>Choć Hellwig zrzekł się części swoich obowiązków, nadal pozostaje aktywny w społeczności Linuxa. Wciąż pełni funkcje opiekuna sterownika NVMe oraz sekcji FreeVXFS. Jego odejście z obszaru mapowania DMA oznacza jednak, że Marek Szyprowski, drugi opiekun tej sekcji, będzie musiał samodzielnie przejąć pełną odpowiedzialność za ten kluczowy element infrastruktury Linuxa.
https://ithardware.pl/aktualnosci/fanatyk_kodu_c_rust_linux-39337.html

#programowanie #rust #technologia #linustorvalds

Linus Torvalds rzucił ostatnio MR. I w sumie dobre komentarze w kodzie.
https://github.com/subsurface/libdc/pull/69

#programowanie #linustorvalds #garmin

>Date: 25 Aug 91 20:57:08 GMT

#linux #linustorvalds #opensource

Linus Torvalds on why desktop Linux sucks - DebConf 14
https://youtu.be/Pzl1B7nB9Kc

#linux #linustorvalds

Najlepszego
#linustorvalds

Eh.

Właśnie instaluje dobremu koledze najnowszego mintaja.

Chop ma coś w okolicach 65 na budziku xd

#oswiadczeniezdupy #linustorvalds #gownowpis #linux

Linux 5.12 został wydany.

:star: Co nowego?
:heavy_plus_sign: Pełna obsługa DualSense, co pozwala na na korzystanie z padów przeznaczonych do konsoli PlayStation na Linuksie.
:heavy_plus_sign: Pełna Obsługa Nintendo 64, smaczek dla miłośników gier klasycznych.
:heavy_plus_sign: Pełna obsługę Adaptive Sync, która zmniejsza klatkowa nie dzięki synchronizowaniu odświeżania wyświetlacza. Rozwiązanie rozwijane jest przez Intel.
:heavy_plus_sign: Ulepszono udostępnianie plików pomiędzy użytkownikami oraz maszynami.
:heavy_plus_sign: Usunięto 32 bitową platformę ARM.
:heavy_plus_sign: Usunięto Intel MID, oraz Intel Simple Firmware Interface
:heavy_plus_sign: Bootwanie linuksa jako "roota" w Microsoft Hypervisor.
:heavy_plus_sign: Dynamiczne zarządzanie temperaturą
:heavy_plus_sign: Obsługa hiperwizora ACRN.

Źródło: http://lkml.iu.edu/hypermail/linux/kernel/2104.3/00596.html