After putting together ecosyste-ms/package-manager-resolvers, I started wondering what dependency resolution algorithm GitHub Actions uses. When you write `uses: actions/checkout@v4` in a workflow file, you’re declaring a dependency. GitHub resolves it, downloads it, and executes it. That’s package management. So I went spelunking into the runner codebase to see how it works. What I found was concerning. Package managers are a critical part of software supply chain security. The industry has spent years hardening them after incidents like left-pad, event-stream, and countless others. Lockfiles, integrity hashes, and dependency visibility aren’t optional extras. They’re the baseline. GitHub Actions ignores all of it. Compared to mature package ecosystems: Feature | npm | Cargo | NuGet | Bundler | Go | Actions ---|---|---|---|---|---|--- Lockfile | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ Transitive pinning | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ Integrity hashes | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ Dependency tree visibility | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ Resolution specification | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ The core problem is the lack of a lockfile. Every other package manager figured this out decades ago: you declare loose constraints in a manifest, the resolver picks specific versions, and the lockfile records exactly what was chosen. GitHub Actions has no equivalent. Every run re-resolves from your workflow file, and the results can change without any modification to your code. Research from USENIX Security 2022 analyzed over 200,000 repositories and found that 99.7% execute externally developed Actions, 97% use Actions from unverified creators, and 18% run Actions with missing security updates. The researchers identified four fundamental security properties that CI/CD systems need: admittance control, execution control, code control, and access to secrets. GitHub Actions fails to provide adequate tooling for any of them. A follow-up study using static taint analysis found code injection vulnerabilities in over 4,300 workflows across 2.7 million analyzed. Nearly every GitHub Actions user is running third-party code with no verification, no lockfile, and no visibility into what that code depends on. **Mutable versions.** When you pin to `actions/checkout@v4`, that tag can move. The maintainer can push a new commit and retag. Your workflow changes silently. A lockfile would record the SHA that `@v4` resolved to, giving you reproducibility while keeping version tags readable. Instead, you have to choose: readable tags with no stability, or unreadable SHAs with no automated update path. GitHub has added mitigations. Immutable releases lock a release’s git tag after publication. Organizations can enforce SHA pinning as a policy. You can limit workflows to actions from verified creators. These help, but they only address the top-level dependency. They do nothing for transitive dependencies, which is the primary attack vector. **Invisible transitive dependencies.** SHA pinning doesn’t solve this. Composite actions resolve their own dependencies, but you can’t see or control what they pull in. When you pin an action to a SHA, you only lock the outer file. If it internally pulls `some-helper@v1` with a mutable tag, your workflow is still vulnerable. You have zero visibility into this. A lockfile would record the entire resolved tree, making transitive dependencies visible and pinnable. Research on JavaScript Actions found that 54% contain at least one security weakness, with most vulnerabilities coming from indirect dependencies. The tj-actions/changed-files incident showed how this plays out in practice: a compromised action updated its transitive dependencies to exfiltrate secrets. With a lockfile, the unexpected transitive change would have been visible in a diff. **No integrity verification.** npm records `integrity` hashes in the lockfile. Cargo records checksums in `Cargo.lock`. When you install, the package manager verifies the download matches what was recorded. Actions has nothing. You trust GitHub to give you the right code for a SHA. A lockfile with integrity hashes would let you verify that what you’re running matches what you resolved. **Re-runs aren’t reproducible.** GitHub staff have confirmed this explicitly: “if the workflow uses some actions at a version, if that version was force pushed/updated, we will be fetching the latest version there.” A failed job re-run can silently get different code than the original run. Cache interaction makes it worse: caches only save on successful jobs, so a re-run after a force-push gets different code _and_ has to rebuild the cache. Two sources of non-determinism compounding. A lockfile would make re-runs deterministic: same lockfile, same code, every time. **No dependency tree visibility.** npm has `npm ls`. Cargo has `cargo tree`. You can inspect your full dependency graph, find duplicates, trace how a transitive dependency got pulled in. Actions gives you nothing. You can’t see what your workflow actually depends on without manually reading every composite action’s source. A lockfile would be a complete manifest of your dependency tree. **Undocumented resolution semantics.** Every package manager documents how dependency resolution works. npm has a spec. Cargo has a spec. Actions resolution is undocumented. The runner source is public, and the entire “resolution algorithm” is in ActionManager.cs. Here’s a simplified version of what it does: // Simplified from actions/runner ActionManager.cs async Task PrepareActionsAsync(steps) { // Start fresh every time - no caching DeleteDirectory("_work/_actions"); await PrepareActionsRecursiveAsync(steps, depth: 0); } async Task PrepareActionsRecursiveAsync(actions, depth) { if (depth > 10) throw new Exception("Composite action depth exceeded max depth 10"); foreach (var action in actions) { // Resolution happens on GitHub's server - opaque to us var downloadInfo = await GetDownloadInfoFromGitHub(action.Reference); // Download and extract - no integrity verification var tarball = await Download(downloadInfo.TarballUrl); Extract(tarball, $"_actions/{action.Owner}/{action.Repo}/{downloadInfo.Sha}"); // If composite, recurse into its dependencies var actionYml = Parse($"_actions/{action.Owner}/{action.Repo}/{downloadInfo.Sha}/action.yml"); if (actionYml.Type == "composite") { // These nested actions may use mutable tags - we have no control await PrepareActionsRecursiveAsync(actionYml.Steps, depth + 1); } } } That’s it. No version constraints, no deduplication (the same action referenced twice gets downloaded twice), no integrity checks. The tarball URL comes from GitHub’s API, and you trust them to return the right content for the SHA. A lockfile wouldn’t fix the missing spec, but it would at least give you a concrete record of what resolution produced. Even setting lockfiles aside, Actions has other issues that proper package managers solved long ago. **No registry.** Actions live in git repositories. There’s no central index, no security scanning, no malware detection, no typosquatting prevention. A real registry can flag malicious packages, store immutable copies independent of the source, and provide a single point for security response. The Marketplace exists but it’s a thin layer over repository search. Without a registry, there’s nowhere for immutable metadata to live. If an action’s source repository disappears or gets compromised, there’s no fallback. **Shared mutable environment.** Actions aren’t sandboxed from each other. Two actions calling `setup-node` with different versions mutate the same `$PATH`. The outcome depends on execution order, not any deterministic resolution. **No offline support.** Actions are pulled from GitHub on every run. There’s no offline installation mode, no vendoring mechanism, no way to run without network access. Other package managers let you vendor dependencies or set up private mirrors. With Actions, if GitHub is down, your CI is down. **The namespace is GitHub usernames.** Anyone who creates a GitHub account owns that namespace for actions. Account takeovers and typosquatting are possible. When a popular action maintainer’s account gets compromised, attackers can push malicious code and retag. A lockfile with integrity hashes wouldn’t prevent account takeovers, but it would detect when the code changes unexpectedly. The hash mismatch would fail the build instead of silently running attacker-controlled code. Another option would be something like Go’s checksum database, a transparent log of known-good hashes that catches when the same version suddenly has different contents. ### How Did We Get Here? The Actions runner is forked from Azure DevOps, designed for enterprises with controlled internal task libraries where you trust your pipeline tasks. GitHub bolted a public marketplace onto that foundation without rethinking the trust model. The addition of composite actions and reusable workflows created a dependency system, but the implementation ignored lessons from package management: lockfiles, integrity verification, transitive pinning, dependency visibility. This matters beyond CI/CD. Trusted publishing is being rolled out across package registries: PyPI, npm, RubyGems, and others now let you publish packages directly from GitHub Actions using OIDC tokens instead of long-lived secrets. OIDC removes one class of attacks (stolen credentials) but amplifies another: the supply chain security of these registries now depends entirely on GitHub Actions, a system that lacks the lockfile and integrity controls these registries themselves require. A compromise in your workflow’s action dependencies can lead to malicious packages on registries with better security practices than the system they’re trusting to publish. Other CI systems have done better. GitLab CI added an `integrity` keyword in version 17.9 that lets you specify a SHA256 hash for remote includes. If the hash doesn’t match, the pipeline fails. Their documentation explicitly warns that including remote configs “is similar to pulling a third-party dependency” and recommends pinning to full commit SHAs. GitLab recognized the problem and shipped integrity verification. GitHub closed the feature request. GitHub’s design choices don’t just affect GitHub users. Forgejo Actions maintains compatibility with GitHub Actions, which means projects migrating to Codeberg for ethical reasons inherit the same broken CI architecture. The Forgejo maintainers openly acknowledge the problems, with contributors calling GitHub Actions’ ecosystem “terribly designed and executed.” But they’re stuck maintaining compatibility with it. Codeberg mirrors common actions to reduce GitHub dependency, but the fundamental issues are baked into the model itself. GitHub’s design flaws are spreading to the alternatives. GitHub issue #2195 requested lockfile support. It was closed as “not planned” in 2022. Palo Alto’s “Unpinnable Actions” research documented how even SHA-pinned actions can have unpinnable transitive dependencies. Dependabot can update action versions, which helps. Some teams vendor actions into their own repos. zizmor is excellent at scanning workflows and finding security issues. But these are workarounds for a system that lacks the basics. The fix is a lockfile. Record resolved SHAs for every action reference, including transitives. Add integrity hashes. Make the dependency tree inspectable. GitHub closed the request three years ago and hasn’t revisited it. * * * **Further reading:** * Characterizing the Security of GitHub CI Workflows - Koishybayev et al., USENIX Security 2022 * ARGUS: A Framework for Staged Static Taint Analysis of GitHub Workflows and Actions - Muralee et al., USENIX Security 2023 * New GitHub Action supply chain attack: reviewdog/action-setup - Wiz Research, 2025 * Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows * GitHub Actions Worm: Compromising GitHub Repositories Through the Actions Dependency Tree * setup-python: Action can be compromised via mutable dependency

Tramvajus Vilniuje – toli gražu ne naujas sumanymas. Pats pirmas projektas parengtas dar prieš 115 metų (1910 m.) ir turbūt tik nedaugelis žmonių yra jį matę. Jeigu projektavimas būtų vykęs keleriais metais anksčiau, gal būtų spėta užbaigti statybos darbus prieš pat I Pasaulinį karą. Jau veikiančios elektrinių tramvajų sistemos dažniausiai išgyvena karus ir sunkius ekonominius laikotarpius, todėl, nors kažkiek pakitęs, Vilnius tramvajus greičiausiai veiktų ir šiandien. Įdomu pažiūrėti, kokias problemas turėjo spręsti tramvajus (ne tik susisiekimo!) ir kokius sprendimus siūlė caro laikų inžinieriai. Beje, šitame tinklaraštyje rašiau ir apie sovietmečio pabaigoje planuotą greitąjį tramvajų, kuris daugeliu aspektų dar neprarado aktualumo. 1910 metų projektas, žinoma, daug smarkiau nutolęs nuo šiandieninių realijų, praktiškai jokie konkretūs sprendiniai jau nebetinka, tačiau kai kurie principai nepaseno – į juos atkreipsiu jūsų dėmesį. Iš pradžių, dar 1893 metais, Vilniuje atsirado **arklinis tramvajus** (konkė). Suplanuotos linijos pažymėtos žemėlapyje raudonai. Pats miestas tuo metu buvo labai kompaktiškas, net nebuvo pradėtas Naujamiesčio užstatymas. **1 pav.** Vilniaus žemėlapis su arklinio tramvajaus linijomis. 1890-1892 m., iš Rusijos Vidaus reikalų ministerijos Techninio-statybinio komiteto parengtos bylos „Arklinių geležinkelių tinklas Vilnios mieste“ (žiūrėti didesniu formatu). Šaltinis: prlib.ru 1910 jau buvo parengtas **elektrinio tramvajaus projektas**. Kodėl jo prireikė? Priežastys įvardijamos Vilniaus miesto Dūmoje pristatytame pranešime: > Trečias projektas, turinti didelę ekonominę ir iš dalies sanitarinę reikšmę miestui, yra elektrinis tramvajus. Šiuo metu mieste veikia Rusijos miesto ir priemiesčio geležinkelių bendrovės arklių tramvajus, įkurtas 1892 m. su koncesijos terminu iki 1929 m. **Šis tramvajus, kurio linijos ilgis yra tik 9,1 varstai [apie 9,7 km], nei techniniu požiūriu, nei patogumo prasme neatitinka pačių elementariausių reikalavimų.** > > Vertimas su DeepL.com. Šaltinis Teigiama, kad arklių trauka ilgiems Vilniaus atstumams netinkama, vagonai per maži (12 sėdimų ir 2 stovimos vietos), linijos parinktos nesėkmingai, nes neatvestos į miesto centrą: > …todėl kasdien konke naudojasi vidutiniškai tik 7225 iš 200 tūkst. gyventojų (apie 13 kelionių vienam gyventojui); o pigaus susisiekimo poreikis mieste, kuriame gyvena neturtingi, bet vis dėlto judrūs ir prekyba užsiimantys gyventojai, yra milžiniškas. Kadangi visa prekybos ir verslo veikla sutelkta tik nedidelėje centrinėje miesto dalyje, prekybininkai, neturėdami pigių transporto priemonių, susibūrę daugiausia ten pat, o būtent ši miesto dalis, kaip seniausia, su siauromis gatvėmis, senais, neaprūpintais namais, kuriuose labai sunku gauti oro ir šviesos, mažiausiai tinka gyventi tokiai didelei gyventojų daliai. > > Vertimas su DeepL.com. Šaltinis Kodėl rašoma, kad arklinis tramvajus nepasiekia miesto centro? Juk 1 paveiksliuke (arklinio tramvajaus projekte) matosi konkės linija per Pilies ir Didžiąją gatvę, skrodžianti visą centrą, kur turbūt ir buvo didžiausia prekybos ir gyventojų koncentracija. Spėju, kad šitas ruožas niekada nebuvo nutiestas! 1898 metų žemėlapyje matosi, kad konkė tik apeidinėja centrą iš šonų, bet niekada jo neperkerta: **2 pav.** Paryškinti konkės maršrutai 1898 metų žemėlapyje, iš K. Matuliausko „Vilniaus transporto istorijos“. Šaltinis Grįžtame prie Vilniaus Dūmoje pristatyto pranešimo, kur buvo išsakyti arklinio tramvajaus trūkumai: > Todėl galima drąsiai tikėtis, kad projektuojamas [elektrinis*] tramvajus, sujungęs miesto centrą su visais priemiesčiais, **sumažins šios miesto dalies [centro*] apkrovą ir perkels gyventojus į pakraščius, o tai sanitariniu požiūriu būtų labai svarbu.** > > **Galiausiai, tramvajus gali padėti išspręsti būsto klausimą,** kuris pastaruoju metu Vilniuje ypač paaštrėjo dėl to, kad butų kainos miesto centre pakilo beveik 30 %. > > Vertimas su DeepL.com. Žvaigždute pažymėtos mano pastabos. Šaltinis Elektrinis tramvajus buvo suvokiamas kaip miesto modernizacijos dalis (kartu su kanalizacija, vandentiekiu), būsto ir higienos problemų sprendimas! Lyginant su arklinio tramvajaus atsiradimo metais, tuo metu Vilnius jau buvo gerokai prasiplėtęs, kaip matyti iš keleriais metais vėliau (1916 m.) vokiečių sudaryto plano: **3 pav.** 1916 m. Vilniaus žemėlapis (padidinti). Šaltinis: lietuvoskartografija.lt Miesto inžinierius aiškinamajame rašte štai taip paaiškino maršrutų parinkimo logiką: > Nustatant tramvajaus linijų maršrutus bet kuriame mieste, reikia vadovautis šiais principais: > > 1. Tramvajaus linijos turi eiti per labiausiai apgyvendintas miesto dalis ir, jei įmanoma, gatvėmis, kurios yra miesto eismo arterijos. > 2. Labiausiai judri, versli miesto dalis, daugiausia jo centras, turi būti sujungta su visais miesto pakraščiais. > 3. Kad linijų tarpusavio išdėstymas būtų toks, kad žmogus, gyvenantis bet kurioje miesto dalyje, galėtų be didelių laiko sąnaudų pasiekti tramvajaus liniją. > 4. Kad techniniai aspektai, tokie kaip gatvės plotis, pakilimai ir posūkiai, būtų kuo geriau patenkinti pasirinkus šią kryptį. > 5. Kad galiausiai linijų tiesimo <…> kaina nebūtų pernelyg didelė. > > > Vertimas su DeepL.com. Šaltinis Šitie principai praktiškai nepaseno! Tai kokie tie suprojektuoti maršrutai? Ir kur galima pamatyti visą projektą? Panašu, kad pats Vilniaus tramvajaus projektas pilna apimtimi internete neegzistuoja. 1. Nuskenuotus brėžinius pirmą kartą pamačiau miestai.net forume: vienas dalyvis 2012 metais juos M. Mažvydo bibliotekoje nuskenavo, įkėlė į internetą ir trumpai aprašė. Paveiksliukai jau prapuolė, tačiau gana naudingas aprašymas išliko. 2. Antrą kartą brėžinius pamačiau feisbuke, geleželinkeliečių grupėse – tuojau parodysiu. Tikriausiai jų pradinis šaltinis yra skaitmenizuota projekto byla Rusijos „Jelcino vardo prezidentinės bibliotekos“ puslapyje. Ten pat yra ir arklinio tramvajaus projektas (1890-1892 m.). 3. Dar yra neblogas portalo obzor.lt straipsnis. Iš šitų trijų šaltinių pabandžiau sudaryti apytikslę tramvajaus maršrutų schemą: **4 pav.** Apytikslė Vilniaus tramvajaus schema. (Žiūrėti didesnę) O minėtame miestai.net forume projektą matęs dalyvis pateikė tokį aprašymą: > **Prie Katedros, aikštėje formuojamas didelis žiedas ir pagrindinis persėdimo mazgas.** > Galutinai patvirtinti maršrutai: > **1**. Stotis – Kalvarijų g. Linija dvikelė, išskyrus Pylimo g. siauras vietas, kur keliai sudvejinti, ir su vienkeliais intarpais prie Aušros vartų. > **1A**. Stotis – Žaliasis Tiltas. > **2**. Katedra – Žvėrynas. Pradžia prie Botanikos sodo. Visa linija dvikelė. > **3**. Pohulianka – Užupis. Linija dvikelė nuo Pohuliankos iki Botanikos sodo. Po to vienkelė su pralankomis 4 stotelėse. > **4.** Skerdykla (dabart. Panerių g. gale) – Katedra – Antakalnis. Linija vienkelė nuo skerdyklos iki Naugarduko g. apačios. Tame ruože dvi pralankos. Antakalnio link nuo Zelionajos g. (dab. K. Jauniaus g.) vienkelė. > **4A**. Katedra – Antakalnis > > Plane išvardintos visos stotelės ir atstumai tarp jų metrais. Yra kontaktinio galios tinklo išdėstymo schemos (t.y. el. energijos perdavimo nuo elektrinės ir iki linijų, įtampos kritimo apskaičiavimai ir kt.), KT atramų išdėstymo schemų, iešmų ir kt. Skersiniai pjūviai kai kurioms vietoms. Tame tarpe ir nauja gatvių kanalizacija vandens surinkimui nuo bėgių pavaizduota. Atramos turėjo būti iš sukniedytų profilių, kai kur tvirtinamas KT prie pastatų. > Buvo numatyta įdiegti elektrinę šviesos signalizaciją, t.y. šviesoforus. > > Siūlomas vagonas su dviašiu vežimėliu, kurio bazė 2,2 m. Vagono ilgis 8,38 m, plotis 2 m, aukštis nuo bėgio 3,295 m be pantografo. Vėžė – 1000 mm. Salono ilgis 4,68 m, abiejuose galuose įlaipinimo aikštelės su mašinisto postais. T.y. buvo siūlomi dvipusiai tramvajai. Aikštelės atviros, bet su durelėmis. Taigi, mašinistas būtų dirbęs lauko sąlygomis, tik kad po stogu ir su priekiniu stiklu… Stabdis orinis, sėdimų vietų 18, stovimų 20. Mediniai suolia palei šonines sienas, t.y. sėdima šonu. > Yra tramvajaus schema pateikta. Gamintojas neaiškus, bet tikriausiai Siemenso firmos ar jo padalinio būtų buvęs. > Šaltinis: A|1, miestai.net O dabar 2-os projekto dalies/bylos brėžiniai (esantys ir skaitmeninėje Jelcino bibliotekoje, ir besimėtantys feisbuke, iš kur juos ir įkeliu). Kaip suprantu, pats projektas suskirstytas į 7 „linijas“ (pagal minėtą obzor.lt straipsnį), turbūt pagal statybų eiliškumą, todėl šitoje antroje byloje nėra visų maršrutų schemos. Pirmoji linija turėjo būti Stotis–Pylimo g.–Vilniaus/Jogailos g.–Žaliasis tiltas–Kalvarijų g. Antroji matyti čia: **5 pav.** Ruožas Stotis–Katedra–Žvėrynas. Matosi žiedas/mazgas Katedros aikštėje. Taip pat neaiški vienkelė atšaka į dab. L. Stuokos-Gucevičiaus gatvę. **6 pav.** Žvėryno tiltas. Tais laikais brėžiniai buvo tikrai malonūs akiai, inžinieriai nepasivargino pavaizduoti ir žolę, debesis, žmones ir įvairias pastatų detales 🙂 Galbūt patys projektai anais laikais buvo techniškai paprastesni, parengiami per trumpesnį laiką, todėl kažkiek laiko paskirti žolės ir debesų piešimui neatrodė kaip resursų švaistymas? **7 pav.** Dab. Gedimino prospektas. Pjūvis. Atkreipkite dėmesį, kad Gedimino (tuo meto Georgijaus) prospekte tramvajaus kontaktinis tinklas tvirtinamas ne ant aplinkinių pastatų, o ant specialių atramų pačiame prospekto viduryje. Tramvajaus infrastruktūra ir apšvietimas tam tikra prasme organizuoja gatvės erdvę, formuoja miesto estetiką. Šitame tinklaraštyje vis stengiuosi pabrėžiu šį punktą: be pagrindinės keleivių pervežimo funkcijos, tramvajus gali suvaidinti didelį vaidmenį transformuodamas miesto erdves, kai perorganizuojamas eismas, sukuriamos žmonėms malonesnės erdvės, pagerinama vietos estetinė kokybė, atgaivinamas miesto centras – gausybė pavyzdžių yra Prancūzijoje, kur per pastaruosius 30 metų įvyko tramvajų renesansas (ateityje įkelsiu nuotraukų). **8 pav.** Dab. Didžioji gatvė. Pjūvis. **9 pav.** Pjūvis per dab. Arklių g. (kairėje) ir Karmelitų g. (dešinėje). **10 pav.** Dab. Lazdynų Pelėdos skveras, kur tramvajams įrengta ir galimybė apsisukti. Arklių g. (apačioje) ir Karmelitų g. (viršuje dešinėje). Tuo metu buvo svarbu nutiesti tramvajų pro patį senamiestį, ten buvo susikoncentravę daug žmonių. Kaip matyti Lisabonoje, šita transporto priemonė gali visai efektyviai išnaudoti ir siauras gatveles, tačiau vis tiek buvo numatyta nugriauti apie 20 namų. Dabar toks variantas jau būtų nepriimtinas, senamiesčio antžeminiu tramvajumi _perkirsti_ nelabai įmanoma. Vokietijoje ir Lenkijoje po II pasaulinio karo tramvajus irgi šiek tiek atsitraukė iš siauresnių senamiesčių vietų. Jeigu projektuotume modernų tramvajų, Pylimo gatvė ir Gedimino prospektas tebeišlieka geriausios įmanomos gatvės antžeminiams ruožams. O norint įvažiuoti giliau į senamiestį, galbūt vienintelis realesnis koridorius būtų Palangos-Liejyklos-Stuokos-Gucevičiaus-Šventaragio g. Tačiau hipotetinis Vilniaus tramvajus pagal geriausius Vakarų Europos pavyzdžius ir nesunaikinant troleibusų – tai jau tema kitiems straipsniams. O kas atsitiko su Vilniaus arkliniu tramvajumi? Jis nustojo kursuoti I Pasaulinio karo metu, arkliai buvo paimti kariuomenės reikmėms, bėgiai tikriausiai liko nenaudojami. Elektrinio tramvajaus tiesimas nebuvo pradėtas galbūt dėl to, kad lenkai 1908 m. Bezdonyse apiplėšė traukinį, kur buvo vežami tramvajui skirti pinigai. Arklinis tramvajus trumpam dalinai atgimė kaip dyzelinis tramvajus – tarp Katedros a. ir Antakalnio 1924-1926 m. kursavo keli vagonai su įmontuotais dyzeliniais varikliais. Dėl vagonų ir motorų nusidėvėjimo veikla nutraukta. Galiausiai 1926 m. visi bėgiai išardyti. Tiesa, 1925-1956 metais dar egzistavo keli visai kitokiomis atkarpomis nutiesti siaurojo geležinkelio ruožai, bet jie buvo skirti anglims ir amunicijai vežti, dažniausiai apvažiuojant patį miestą, todėl keleiviams vargiai būtų galėję kaip nors pasitarnauti. ⬤ Nepraleiskite naujų straipsnių: sekite tinklaraštį feisbuke ir telegrame. * Koks turėjo būti Vilniaus greitasis tramvajus? * Traukiniai Vilniuje: kam jų reikia? * Brėžiniuose likusi Pilaitė * Kiek greitųjų traukinių Lietuvoje turėsime 2030 metais? * Idėja: naktiniai traukiniai į Lietuvą #### Nuorodos * Neakivaizdinis Vilnius: Vilnius archyvuose: elektrinis tramvajus, kuriam nelemta atsirasti * Obzor.lt: Mintys apie elektrinį tramvajų (rusiškai) * Kęstutis Matuliaukas: „Vilniaus transporto istorija“, 2016 m. * Nuotraukos su arkliniais tramvajais. Jis neužsigauna, vadinamas “konke”: pasivėžinsim arkliniu tramvajumi, aidai.lt ### Dalintis: * Click to share on Facebook (Opens in new window) Dalintis Facebook * Click to share on LinkedIn (Opens in new window) LinkedIn * Click to share on Reddit (Opens in new window) Reddit * Click to email a link to a friend (Opens in new window) Email * Kaip Įkeliama... ### _Susiję straipsniai_

SQL Query Editor and Executor

Comments

Molly is an improved Signal app for Android

Open-Source-Software builds the foundations of digital infrastructure in big parts - in administration, economy, science and daily life. Even the current coalition agreement of the Federal Government mentions Open-Source-Software as a fundamental building block for the achievement of digital sovereignty. However, the work done by thousands of volunteers for this goal is not recognised as volunteering, neither fiscally nor in terms of funding. This imbalance between societal importance and legal

FileZilla Pro Download. Contribute to x011/FileZilla-Pro-Download development by creating an account on GitHub.

Bring Bathroom Doors Back to Hotels