TweakNews.net - Kot je ugotovila komisija, ki jo je ustanovil lastnik avtonomnih avtobusov, podjetje Connexxion, je prišlo do nesreče zaradi nenavadnega spleta okoliščin. Zadeva se je začela zapletati, ko je eno izmed vozil izgubilo povezavo s centralnim računalnikom. Zaradi tega se je avtobus ustavil in čakal, da se povezava ponovno vzpostavi, a ker je stal ravno na mostu, je s tem nekaj časa blokiral progo, preden se je umaknil na postajališče.
Druga dva avtobusa sta med tem čakala in ob sprostitvi ovire obenem prečkala most. Drug drugega sta videla prepozno, ker je sistem za zaznavo ovir prilagojen zaznavanju mirujočih objektov. Zavorna pot je bila tako predolga in sledila je nesreča. Proizvajalec omenjenih vozil, 2getthere, sedaj dela na rešitvah za preprečevanje tovrstnih primerov v prihodnosti. Izboljšali bodo pokritost s signalom, osvežili programsko opremo in tudi predpisali nove procedure. Vse skupaj naj bi bilo nared še pred novim letom, potem pa bodo začeli s testno fazo preostalih 4 avtobuskov. Kdaj se jima bosta pridružila v bitki ranjena tovariša, še ni znano, priporočamo ogled proizvajalčeve strani.
V uradnem pojasnilu žal ni dovolj jasno povedano ali je do nesreče prišlo zaradi nadzornega centra (ki je dopustil dva avtobusa na isti lokaciji) ali sistema za detekcijo ovir, zato vam ponujamo praktičen nasvet - do izdaje popravka nikar ne tecite k ali stran od avtomatiziranih busov. Stojte pri miru, da se vam lahko izognejo.
Novice » Znanost in tehnologija » Vzrok nesreče med avtonomnima minibusoma
Kami ::
Jah samo 1 main PC, moglo bi bit več backup strežnikov.
Torej če je main strežnik down je vse v šitu :)
Ne glih dobro razmišlanje
Torej če je main strežnik down je vse v šitu :)
Ne glih dobro razmišlanje
Kami ::
Jap res je malo prehitro sem prebral lahko je več razlogov, da je PC zgubo povezavo z centralinim PC-jem lahko, da je kaj odpovedalo itd :)
my bad
my bad
Utk ::
Jah zmeraj bo kakšna nesreča...takšna se recimo (naprimer) statistično zgodi na 10 let, to napako bojo odpravli, ostale bodo še potencialne nesreče, ki se stastistično zgodijo na 20,50,100 let...ta čas se bo samo podaljševal, še zmeraj bo pa lahko kaj narobe, kot pri vsaki stvari.
B-D_ ::
Vsak program je buggy ko izide. Nemogoče je vse buge izključit, zato se takšne zadeve tudi dogajajo.
Kdor pa tupo trdi da je kao treba vse take možnosti izključit preden pride zadeva ven iz simulatorja pa očitno res še nikoli ni sprogramiral več kot helloworld v lajfu.
Kdor pa tupo trdi da je kao treba vse take možnosti izključit preden pride zadeva ven iz simulatorja pa očitno res še nikoli ni sprogramiral več kot helloworld v lajfu.
Brane2 ::
če bi jim firmware zrihtali slovenski ROBOBRCARJI, bi prevoz po mestu sploh znal postati sila zanimiv... 
On the journey of life, I chose the psycho path.
Highlag ::
Hroščke bodo pobili. Ni to en sistem kot recimo Windows ali linux z miljoni vrstic kode.
Avtomatiziran transport recimo uporabljajo v Roterdamskem pristanišču, kjer računalnik skrbi naenkrat za preko 130 avtomatiziranih tovornjakov, ki prevažajo kontejnerje od razkladalnih žerjavov do odlagalnega mesta, ter seveda nazaj ko je to potrebno.
Glede na hitrost dela se tam tisti tovornjaki ne zaletavajop kaj dosti, ker bi jih drugače že zamenjali vozniki
Avtomatiziran transport recimo uporabljajo v Roterdamskem pristanišču, kjer računalnik skrbi naenkrat za preko 130 avtomatiziranih tovornjakov, ki prevažajo kontejnerje od razkladalnih žerjavov do odlagalnega mesta, ter seveda nazaj ko je to potrebno.
Glede na hitrost dela se tam tisti tovornjaki ne zaletavajop kaj dosti, ker bi jih drugače že zamenjali vozniki
Never trust a computer you can't throw out a window
Zgodovina sprememb…
- spremenil: Highlag ()
BluPhenix ::
B-D_ ali pa nekdo ob tvojih komentarjih pomisli, da nisi programiral nikoli nič drugega kot za Windows (če si kdaj)
Ja take buge je kao treba vse oziroma čimveč predvideti. Veš to so drugačni sistemi kot windows. Programerji takih sistemov so najboljše plačani programerji na svetu in so bolj redki. Tukaj se gre za real time operacijske sisteme, ki morajo delati kot je treba. Kupec takega programa ne podpiše EULE, kjer je zapisano, da proizvajalec softwareja ni kriv za škodo, ki jo le-ta povzroči. Velik del razvoja takih sistemov ni kot v windows in sploh PC sistemih iskanje vidnih bugov, takih ponovljivih, ampak iskanje tistih, ki se zgodijo le ob določenih pogojih, se pravi ne pogosto ponovljivih. To je pri programiranju takih sistemov največji izziv, iskanje in predvidevanje čim večjega števila takih bugov, ampak ne skozi klasično debugiranje, ne tukaj mora programer velikokrat v kodi opaziti, kaj bi se lahko zgodilo. Bo treba kaj prebrati na to temo, ne samo nekaj bluziti.
Highlag, nimajo glih miljonov vrstic kode imajo pa na deset in nekateri stotisoče in to navadno v assemblerju.
To je lepo izhajanje ja, ah sej je ves software buggy ob izidu... pač 150 potnikov v letalu je pomrlo, ker je pač pilot stisnil dva gumba, ki jih nebi smel skupaj...
Tukaj je (sklepam iz novice) prišlo par skoraj naključnih dejavnikov. Avtobusek je izgubil zvezo in se ustavil na mostu (ki je, predvidevam enosmeren medtem ko so drugi deli proge dvosmerni). Avtobuska ki sta prišla sta se ustavila na taki razdalji, da se nista mogla ognit drug drugemu. Vsekakor bi moral to programer predvideti in posimulirati, kaj se zgodi v takih primerih, med drugim bi moral tudi server ugotoviti, da ni uredu če se oba avtobuska istočasno poženeta preko mostička, oziroma bi moral že sam centrali načunalnik videti, da sta na collision course, neodvisno od njihovih senzorjev za predmete na progi. V takem primeru je šlo v bistvu za čisto nekompetentnost programerja, ki bi moral tako situacijo predvideti. Tako da to ni toliko bug, kot pa slabo zasnovan software.
Kdor pa tupo trdi da je kao treba vse take možnosti izključit preden pride zadeva ven iz simulatorja pa očitno res še nikoli ni sprogramiral več kot helloworld v lajfu.
Ja take buge je kao treba vse oziroma čimveč predvideti. Veš to so drugačni sistemi kot windows. Programerji takih sistemov so najboljše plačani programerji na svetu in so bolj redki. Tukaj se gre za real time operacijske sisteme, ki morajo delati kot je treba. Kupec takega programa ne podpiše EULE, kjer je zapisano, da proizvajalec softwareja ni kriv za škodo, ki jo le-ta povzroči. Velik del razvoja takih sistemov ni kot v windows in sploh PC sistemih iskanje vidnih bugov, takih ponovljivih, ampak iskanje tistih, ki se zgodijo le ob določenih pogojih, se pravi ne pogosto ponovljivih. To je pri programiranju takih sistemov največji izziv, iskanje in predvidevanje čim večjega števila takih bugov, ampak ne skozi klasično debugiranje, ne tukaj mora programer velikokrat v kodi opaziti, kaj bi se lahko zgodilo. Bo treba kaj prebrati na to temo, ne samo nekaj bluziti.
Highlag, nimajo glih miljonov vrstic kode imajo pa na deset in nekateri stotisoče in to navadno v assemblerju.
To je lepo izhajanje ja, ah sej je ves software buggy ob izidu... pač 150 potnikov v letalu je pomrlo, ker je pač pilot stisnil dva gumba, ki jih nebi smel skupaj...
Tukaj je (sklepam iz novice) prišlo par skoraj naključnih dejavnikov. Avtobusek je izgubil zvezo in se ustavil na mostu (ki je, predvidevam enosmeren medtem ko so drugi deli proge dvosmerni). Avtobuska ki sta prišla sta se ustavila na taki razdalji, da se nista mogla ognit drug drugemu. Vsekakor bi moral to programer predvideti in posimulirati, kaj se zgodi v takih primerih, med drugim bi moral tudi server ugotoviti, da ni uredu če se oba avtobuska istočasno poženeta preko mostička, oziroma bi moral že sam centrali načunalnik videti, da sta na collision course, neodvisno od njihovih senzorjev za predmete na progi. V takem primeru je šlo v bistvu za čisto nekompetentnost programerja, ki bi moral tako situacijo predvideti. Tako da to ni toliko bug, kot pa slabo zasnovan software.
Podpisa ni več, ker so me poskušali asimilirati.
Looooooka ::
to je bug.
ce delas software za varno voznjo in voznja ni varna je to bug.
it's that simple.
bug je pa posledica slabga programiranja,ki je posledica slabga planiranja,ki je posledica slabga predvidevanja.
in vse to se popravi,ko se najde bug.
temu bugu userji recejo BUG,programerji pa nepredvidljiva okoliscina.
seveda ce bi kdo sedel v avtobusu bi to bil BUG in bi zato nekdo bil odgovoren.In ce bi bil nekdo za to odgovoren bi to pomenil da so nekomu dokazal BUG in ne nepredvidljivo okoliscino =).
In glih zato ker ko se vsedes v avtobus brez voznika NE podpise EULE bo nekdo na konc kriv ce se tak avtobus sam od sebe zaleti.
Point here is...BUG BUG BUG BUF FREAKING BUG BUG BUG.
ce delas software za varno voznjo in voznja ni varna je to bug.
it's that simple.
bug je pa posledica slabga programiranja,ki je posledica slabga planiranja,ki je posledica slabga predvidevanja.
in vse to se popravi,ko se najde bug.
temu bugu userji recejo BUG,programerji pa nepredvidljiva okoliscina.
seveda ce bi kdo sedel v avtobusu bi to bil BUG in bi zato nekdo bil odgovoren.In ce bi bil nekdo za to odgovoren bi to pomenil da so nekomu dokazal BUG in ne nepredvidljivo okoliscino =).
In glih zato ker ko se vsedes v avtobus brez voznika NE podpise EULE bo nekdo na konc kriv ce se tak avtobus sam od sebe zaleti.
Point here is...BUG BUG BUG BUF FREAKING BUG BUG BUG.
hokuto ::
Tole ni ravno bug, ampak pomanjkljiv software. Namrec to je osnovno, da se tile buski vsaj med sabo ne zaletavajo, saj je bolj ali manj trivialno dosec, da se prakticno cel cas zavedajo pozicije drug drugega in takale nesreca je popolnoma nepotrebna. Bug bi recimo lahko bil kriv za to, da je prvi busek ostal brez povezave, za samo nesreco potem pa ne, ker so buski ravnali tocno tako kot so bili sprogramirani in se vseeno zaleteli. Pac so pozabili dodat en check, ce se kateri od buskov bliza delu kjer ni prostora za dva in v katero smer vozeci ima v tem primeru prednost, kateri pa mora pocakat.
doke!
Roadkill ::
Ko že govorite o bugih, bi jaz samo omenil, da sem iz obeh člankov do sedaj dobil občutek, da tole ni bil nek popoln končni produkt, ampak beta verzija uporabljena v dejanskem testiranju. Torej testiranju končnih uporabnikov, kjer se šele lahko pojavijo tisti bugi, ki se pojavijo le pri dejanski uporabi.
Dokler niste testirali kakega kompleksnega sistema v razvoju, si vrjetno težko predstavljate, samo koliko testiranja je potrebnega, da zadevo dejansko lahko proglasiš kot FINAL verzijo.
Pa ne mi tle jamrat, da bi moglo jit tle drugač, ker so vpleteni "mimoidoči" in pa živi potniki. Zame je to povsem isto, kot neka bančna aplikacija ali kaj podobnega. Zadeva gre v produkcijo, šele, ko se nekdo odloči, da je delujoča, a se vendar vedno ve, da se lahko zgodijo nepredvidljive stvari in so žrtve... takšne ali drugačne.
Če bi blo po vaše, bi se pa mogla narest najprej zlo kompletna analiza "pravilnosti programa", potem se pa še 5 let testirat znotraj firme in potem uporabit v praksi. In ravno zaradi takega mišlenja se zelo upočasnjuje razvoj zdravil in pa tudi ostalih zadev. Ker so firme prisiljene ukinit proizvodnjo zdravil, ko jim umre en testni osebek, pa čeprav je zdravilo 99% učinkovito pri zdravljenju _ustavi random smrtonosno bolezen_.
Hočem povedat, da je treba mal reskirat oziroma malo manj gledat na tist promil napak in se bolj osredotočit na dejanski razvoj. Če ti testiraš svojo aplikacijo gotovo spregledaš določene stvari in tako traja leta preden porihtaš vse malenkosti. Ko pa daš to med ljudi, se pa take stvari pokažejo takoj in je tako razvoj veliko hitrejši.
Ja... trikrat sem isto stvar napisal... :)
Dokler niste testirali kakega kompleksnega sistema v razvoju, si vrjetno težko predstavljate, samo koliko testiranja je potrebnega, da zadevo dejansko lahko proglasiš kot FINAL verzijo.
Pa ne mi tle jamrat, da bi moglo jit tle drugač, ker so vpleteni "mimoidoči" in pa živi potniki. Zame je to povsem isto, kot neka bančna aplikacija ali kaj podobnega. Zadeva gre v produkcijo, šele, ko se nekdo odloči, da je delujoča, a se vendar vedno ve, da se lahko zgodijo nepredvidljive stvari in so žrtve... takšne ali drugačne.
Če bi blo po vaše, bi se pa mogla narest najprej zlo kompletna analiza "pravilnosti programa", potem se pa še 5 let testirat znotraj firme in potem uporabit v praksi. In ravno zaradi takega mišlenja se zelo upočasnjuje razvoj zdravil in pa tudi ostalih zadev. Ker so firme prisiljene ukinit proizvodnjo zdravil, ko jim umre en testni osebek, pa čeprav je zdravilo 99% učinkovito pri zdravljenju _ustavi random smrtonosno bolezen_.
Hočem povedat, da je treba mal reskirat oziroma malo manj gledat na tist promil napak in se bolj osredotočit na dejanski razvoj. Če ti testiraš svojo aplikacijo gotovo spregledaš določene stvari in tako traja leta preden porihtaš vse malenkosti. Ko pa daš to med ljudi, se pa take stvari pokažejo takoj in je tako razvoj veliko hitrejši.
Ja... trikrat sem isto stvar napisal... :)
Ü
BluPhenix ::
Roadkill pri takih stvareh pa ne moreš glih neki reskirat. Danes sploh ne, ko te ena tožba lahko spravi na kolena, še posebno če se v njo vključi še nekaj miljonov ljudi, ki so bili potencialno ogroženi.
Take stvari morajo iti na trg pripravljene in pretestirane.
Loooooka: zame to še vedno ni bug. Sej zadnje čase se je sprejelo kot bug vsaka napaka v programu, ampak ni prav. Če je software slabo splaniran (recimo tako situacijo bi morali predvideti, ker pa le ni tako naključna: zadeve se pogovarjajo brezžično, v vsakem trenutku lahko zgubijo zvezo, kaj se zgodi, ko jo zgubijo, kje so kritične lokacije in kaj se zgodi, če zgubi zvezo na takih lokacijah...). Bug je zame bolj to, ko ti enkrat sprogramiraš eno zadevo, koda je pravilna, vseeno pa se sistem ne obnaša kot bi moral, zaradi razlčnih dejavnikov. Ali pa recimo ko delaš v real time operacijskem sistemu in imaš dva taska pravilno napisana vendar ker si pozabil nekaj povleči iz stacka nekaj ne deluje pravilno. Se pravi si napačno sprogramiral kodo.
Take stvari morajo iti na trg pripravljene in pretestirane.
Loooooka: zame to še vedno ni bug. Sej zadnje čase se je sprejelo kot bug vsaka napaka v programu, ampak ni prav. Če je software slabo splaniran (recimo tako situacijo bi morali predvideti, ker pa le ni tako naključna: zadeve se pogovarjajo brezžično, v vsakem trenutku lahko zgubijo zvezo, kaj se zgodi, ko jo zgubijo, kje so kritične lokacije in kaj se zgodi, če zgubi zvezo na takih lokacijah...). Bug je zame bolj to, ko ti enkrat sprogramiraš eno zadevo, koda je pravilna, vseeno pa se sistem ne obnaša kot bi moral, zaradi razlčnih dejavnikov. Ali pa recimo ko delaš v real time operacijskem sistemu in imaš dva taska pravilno napisana vendar ker si pozabil nekaj povleči iz stacka nekaj ne deluje pravilno. Se pravi si napačno sprogramiral kodo.
Podpisa ni več, ker so me poskušali asimilirati.
keber ::
Aha, zanimivo. Glavni design flaw je pravzaprav centralna enota ter pomanjkanje medsebojnega komuniciranja. Če bi avtobuski lahko komunicirali med sabo, verjetno do nesreče ne bi prišlo. Pa backup sistemi bi tudi morali biti.
antonija ::
Vsak zacetnik je tezak...
Statistically 3 out of 4 involved usually enjoy gang-bang experience.
BluPhenix ::
keber, v tem primeru bi bil baskup edino kakšen drugačen prenos podatkov. Je pa sedaj odvisno ali je avtobusek izgubil povezavo s centralo (prolem v avtobusku, vprašljiva možnost backupa) ali je server izgubil povezavo (v tem primeru bi se moralo dati nekaj narediti).
Ja komunikacija med avtobuski tudi nebi bila slaba ideja, ampak to dela že centralni računalnik, zato neke take potrebe niti ni, pa tudi vprašanje, če bi si bila sposobna 2 avtobuska izmenjavat podatke na veliki razdalji, z enim kupom ovir med njima.
Še vedno ostajam pri istem: slaba zasnova.
Ja komunikacija med avtobuski tudi nebi bila slaba ideja, ampak to dela že centralni računalnik, zato neke take potrebe niti ni, pa tudi vprašanje, če bi si bila sposobna 2 avtobuska izmenjavat podatke na veliki razdalji, z enim kupom ovir med njima.
Še vedno ostajam pri istem: slaba zasnova.
Podpisa ni več, ker so me poskušali asimilirati.
Poldi112 ::
Roadkill, se ne strinjam. Ravno zaradi tvojega mišlenja in pritiska trga je ogromno software-a tako zelo hroščatega. In stroški so za končnega uporabnika višji, ker se mu aplikacija ali sesuva ali deluje napačno.
Sploh pa je to nesprejemljivo v bolj kritičnih aplikacijah. Ne vem kaj ima hitrost razvoja veze s tem da daješ beta verzije v produkcijo.
Sploh pa je to nesprejemljivo v bolj kritičnih aplikacijah. Ne vem kaj ima hitrost razvoja veze s tem da daješ beta verzije v produkcijo.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
hokuto ::
Roadkill motis se, metat polizdelke med ljudi upocasnjuje njihovo uveljavljanje, ne pa nasprotno kot ti trdis (upas), se posebej, ce gre za obcutljiv izdelek, ki lahko zelo resno prizadane uporabnike in/ali nedolzne "opazovalce". Zakaj? Zaradi tega kar sta se ze rekla BluPhenix in Poldi, pa tudi zaradi tega, ker z vsakim neuspehom (pri obcutljivih zadevah gre lahko za zelo zelo bolec neuspeh) povecujes nezaupanje med ljudmi, ki so potem toliko manj pripravljeni sprejeti ta in celo sorodne izdelke. Slabo delovanje je izredno mocna negativna reklama, ki se ji je vecinoma zelo tezko zoperstavit.
doke!
Stepni Volk ::
Za Roadkilla: 10 najhujših programskih hroščev v zgodovini, poglej še malce temo o Puščavsko zmagoslavje robotskih vozil, kjer sem prevedel Chipov članek s podobno vsebino, plus o možnih poteh softwareske industrije pri odpravljanju napak, plus kako se je software do sedaj obnesel v aviaciji.
Končno besedo imajo, tako kot sem v zgornji temi robotskih vozil omenil, pravniki. Če lahko tožiš McDonald, ker si se spekel z vročo kavo, kaj bi naredil povprečen američan sedeč v takšnem avtobusku?
Končno besedo imajo, tako kot sem v zgornji temi robotskih vozil omenil, pravniki. Če lahko tožiš McDonald, ker si se spekel z vročo kavo, kaj bi naredil povprečen američan sedeč v takšnem avtobusku?
BigWhale ::
Ne omenjaj vec McDonaldsa in vroce kave. Stvar je prerasla v urbano legendo. Poisci na wikipedii. Tista tozba je povsem legitimna in upravicena. Vroca kava gor ali dol.
Roadkill ::
Men se samo zdi zanimiv stavek: V avtu bugov ne sme bit.
Najboljš, da kar taki, ki to pravijo sprogramirajo tak software.
Torej software, ki ima za vhodne podatke kar realni svet in mora vozit avto. :)
Najboljš, da kar taki, ki to pravijo sprogramirajo tak software.
Torej software, ki ima za vhodne podatke kar realni svet in mora vozit avto. :)
Ü
Stepni Volk ::
Saj obstoječi avtomobili so tudi "polni bugov". Včasih katastrofalnih, drugič manj, KLIK
Losov test razreda A se spomnimo vsi.
Mazda 6 lahko ob vseh vklopljenih uporabnikih elektrike skuri procesor, kar pomeni, da gre motor.
Mercedes Benz E klase ima veliko elektronskih napak. Malce tudi zaradi 2km napeljave.
Losov test razreda A se spomnimo vsi.
Mazda 6 lahko ob vseh vklopljenih uporabnikih elektrike skuri procesor, kar pomeni, da gre motor.
Mercedes Benz E klase ima veliko elektronskih napak. Malce tudi zaradi 2km napeljave.
Zgodovina sprememb…
- spremenilo: Stepni Volk ()
hokuto ::
bigwhale... saj stepni ni rekel, da je tista tozba neupravicena... samo, da, ce je tista upravicena, je potem marsikatera druga, ki bi lahko zrasla na problemih povezanih s tole temo, se toliko bolj. In mimogrede ne glede na upravicenost te razvpite tozbe, se zmeraj ostaja dejstvo, da je precej nerazumnih tozb, nerazumno dobljenih z zelo nerazumnimi odskodninami.
doke!
BigWhale ::
Saj so bili avti polni bugov tudi prej, preden so bili 'elektronski'. Pa kaj? Je kdo jokal zaradi tega?
Najbrz kdo obcasno je, tako kot to pocnejo danes in tako kot bodo to poceli v prihodnosti. Pa je cisto vseeno, kdo jih bo vozil clovek ali racunalnik. Tisti, ki se bodo pa zaletavali oziroma svojci zrtev, bodo pa itak vedno krivili tretjo stvar za nesreco.
"Ja, ce bi mel avto boljse bremze, bi se lahko ustavil!"
"Ja, ce ne bi mel racunalnika in bi on sam vozil, bi se sigurno prej ustavil..."
"Ja, ce bi imel leseno kocijo in dva konja, bi lahko preskocil luknjo na cesti..."
In podobne traparije. Racunalnik je ze precej superioren od cloveka. V voznji najbrz se ne, ker se ni bilo prakticne uporabe. Bo pa. In komaj cakam, da bo. Se bo pa racunalnik najbrz 1000x manj motil (kljub vsem bugom) kot clovek in bo kakih 1000x bolj natancen in 1000x hitrejsi pri odzivanju na razlicne situacije.
Najbrz kdo obcasno je, tako kot to pocnejo danes in tako kot bodo to poceli v prihodnosti. Pa je cisto vseeno, kdo jih bo vozil clovek ali racunalnik. Tisti, ki se bodo pa zaletavali oziroma svojci zrtev, bodo pa itak vedno krivili tretjo stvar za nesreco.
"Ja, ce bi mel avto boljse bremze, bi se lahko ustavil!"
"Ja, ce ne bi mel racunalnika in bi on sam vozil, bi se sigurno prej ustavil..."
"Ja, ce bi imel leseno kocijo in dva konja, bi lahko preskocil luknjo na cesti..."
In podobne traparije. Racunalnik je ze precej superioren od cloveka. V voznji najbrz se ne, ker se ni bilo prakticne uporabe. Bo pa. In komaj cakam, da bo. Se bo pa racunalnik najbrz 1000x manj motil (kljub vsem bugom) kot clovek in bo kakih 1000x bolj natancen in 1000x hitrejsi pri odzivanju na razlicne situacije.
Thomas ::
Se strinjam z Roadkillom. Cagavost ne pelje nikamor, čakanje na popolen sistem pa tudi jemlje življenja.
Pa naj bodo to zdravila, avtonomni šoferji in še marsikaj!
Pa naj bodo to zdravila, avtonomni šoferji in še marsikaj!
Man muss immer generalisieren - Carl Jacobi
antonija ::
Pol pa prepovedat zdravila, avtonomne soferje in marsikaj dokler jih ne spravimo do popolnega stanja pa je stvar resena. Pol bomo manj zivlenj izgubili
Statistically 3 out of 4 involved usually enjoy gang-bang experience.
MrStein ::
Pac so pozabili dodat en check
Ja. Temu se reče "bug".
Ali "napaka", če komu mogoče beseda "bug" ne leži.
Če ne dela prav, ima napako. Simpl. (ob predpostavki, da je okolje OK. Če TV pod vodo ne dela, to ni napaka TV aparata recimo)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Zgodovina sprememb…
- spremenil: MrStein ()
BluPhenix ::
Ma kakšne primerjave delaš ti? Kaj, če TV ne dela pod vodo je bug?
EDIT: po wikipediji je bug:
A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program's source code or its design
Torej bi se lahko reklo res, da je šlo za "bug", čeprav meni to ni všeč, saj je naprava delala kot je bila mišljena da dela, torej ni prišlo do trčenja zaradi napačnega izvajanja programa, ampak ker je programer narobe načrtoval stvar. Problem pri tem je, da pote ljudje ne mislijo, da je stvar naredil nek tri-četrt sposoben programer, ampak da tehnologiji ne gre zaupati, čeprav je delovala kot je bila narejena.
EDIT: po wikipediji je bug:
A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program's source code or its design
Torej bi se lahko reklo res, da je šlo za "bug", čeprav meni to ni všeč, saj je naprava delala kot je bila mišljena da dela, torej ni prišlo do trčenja zaradi napačnega izvajanja programa, ampak ker je programer narobe načrtoval stvar. Problem pri tem je, da pote ljudje ne mislijo, da je stvar naredil nek tri-četrt sposoben programer, ampak da tehnologiji ne gre zaupati, čeprav je delovala kot je bila narejena.
Podpisa ni več, ker so me poskušali asimilirati.
Zgodovina sprememb…
- spremenil: BluPhenix ()
Stepni Volk ::
Vse napake so vedno človeške. Kakor kaže v danem primeru, niso integrirali sistema za izgoibanje mirujočim IN PREMIKAJOČIM oviram.
Je to hrošč?
Hreščalo je, ko je počilo. A se mi ne zdi, da bi to poimenoval: hrošček. Zame bi to bil, če sistem ne bi opazil ovir, ki se premikajo s hitrostjo 3,4789 km/h. Ali če zadeva ne bi deloval ob določeni temperatudi in pritisku.
Zakaj so bili avtobuski opremljeni le s sistemom za detekcijo mirujočih ovir?
- Ker so verjetno planirali traso, tako, da drugih vozil ni.
. Ker so predvidevali, da na Nizozemskem vsi potniki lepo čakajo na postaji, ter v primeru, da jim kaj pade na "avtobuskno cesto", zadevo v mirujočem stanju poberejo.
- Ker so planirali, da bo vse premikajoče objekte - avtobuske nadzorovala centrala (in jih potem ni, ker so snovalci centrale predvideavali, da avtobusek ima detektor za premikajoče se objekte?)
V aviaciji imajo lep izrek: "Vsa dognanja in procedure so napisane v krvi."
Seveda takrat, ko so to izrekli ni bilo računalnikov, ki bi nadzirali stvari. Takrat je v cockpitu sedel še tretji človek in na tleh se je prtljaga checikrala ročno.
Je to hrošč?
Hreščalo je, ko je počilo. A se mi ne zdi, da bi to poimenoval: hrošček. Zame bi to bil, če sistem ne bi opazil ovir, ki se premikajo s hitrostjo 3,4789 km/h. Ali če zadeva ne bi deloval ob določeni temperatudi in pritisku.
Zakaj so bili avtobuski opremljeni le s sistemom za detekcijo mirujočih ovir?
- Ker so verjetno planirali traso, tako, da drugih vozil ni.
. Ker so predvidevali, da na Nizozemskem vsi potniki lepo čakajo na postaji, ter v primeru, da jim kaj pade na "avtobuskno cesto", zadevo v mirujočem stanju poberejo.
- Ker so planirali, da bo vse premikajoče objekte - avtobuske nadzorovala centrala (in jih potem ni, ker so snovalci centrale predvideavali, da avtobusek ima detektor za premikajoče se objekte?)
V aviaciji imajo lep izrek: "Vsa dognanja in procedure so napisane v krvi."
Seveda takrat, ko so to izrekli ni bilo računalnikov, ki bi nadzirali stvari. Takrat je v cockpitu sedel še tretji človek in na tleh se je prtljaga checikrala ročno.
Zgodovina sprememb…
- spremenilo: Stepni Volk ()
MrStein ::
BluPhenix:
Ni. Saj sem napisal : Če TV pod vodo ne dela, to ni napaka TV aparata
Aja, mišljeno je bilo, da se bo bus zaletaval ?
Šur, seveda, zakaj pa ne. Če ne bi bilo nesreč, bi kdo lahko posumil, da je vse skup le iluzija ...
Kaj, če TV ne dela pod vodo je bug?
Ni. Saj sem napisal : Če TV pod vodo ne dela, to ni napaka TV aparata
saj je naprava delala kot je bila mišljena da dela
Aja, mišljeno je bilo, da se bo bus zaletaval ?
Šur, seveda, zakaj pa ne. Če ne bi bilo nesreč, bi kdo lahko posumil, da je vse skup le iluzija ...
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
BluPhenix ::
Ni napaka tv aparata, je pa po tem kar je tukaj napisano bug, napaka v snovanju izdelka. Aja mišljeno je, da televizija pod vodo crkava.
To itak ne pelje več nikamor, sej smo nekako prišli do podobnih zaključkov, le po drugačnih poteh. Se pravi zajebali so razvijalci ne pa tehnologija.
To itak ne pelje več nikamor, sej smo nekako prišli do podobnih zaključkov, le po drugačnih poteh. Se pravi zajebali so razvijalci ne pa tehnologija.
Podpisa ni več, ker so me poskušali asimilirati.
MrStein ::
TV ne dela pod vodo. To ve vsak. Piše tudi v dokumentaciji.
Dela na sobnih tempraturah in sobnih nivojih vlažnosti.
Pod vodo ne dela.
Da pa bus ne bi po cestah in mostovih vozil... no ja, kar čuden bus mora potem to biti.
Dela na sobnih tempraturah in sobnih nivojih vlažnosti.
Pod vodo ne dela.
Da pa bus ne bi po cestah in mostovih vozil... no ja, kar čuden bus mora potem to biti.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Shared space - Ljubljana (strani: 1 2 3 4 5 6 7 8 )Oddelek: Na cesti | 58816 (45462) | TESKAn |
| » | Zakaj tako velik procent smrtnih nesreč ob padcu aviona (strani: 1 2 3 4 5 6 )Oddelek: Znanost in tehnologija | 24240 (19539) | antonija |
| » | sprevodnik na vlaku, kaj že?Oddelek: Loža | 4437 (2939) | budili |
| » | Vzrok nesreče med avtonomnima minibusomaOddelek: Novice / Znanost in tehnologija | 3797 (2628) | MrStein |
| » | Robotska minibusa sta se zaletela (strani: 1 2 3 )Oddelek: Novice / Znanost in tehnologija | 11890 (9591) | Nejc Pintar |