Inlägg

Inlägg som Sidde har skrivit i forumet
Av Sidde
Skrivet av sweborn:

Mercas kommunikation är väl att de kan byta sidepodkoncept till Imola? Om de då fortfarande vill, dvs de kommer att fortsätta kämpa.

Fast det vara det som de kommunicerade redan på försäsongstesterna från dag 1 och är det "planerade" uppdateringarna på dagens koncept inklusive sidepod-uppdateringarna. Alltså det som skulle komma till Imola.

Sedan denna race-helg är det nya bud där Wolff nu gått ut med att de måste tänka om helt.
Känns som man skulle uttrycka nedan stycke väldigt annorlunda om man planerat uppdateringarna.

Citat:

"On Friday, a gloomy Hamilton said his team are on the "wrong track", had fallen further behind his rivals and questioned whether Mercedes' concept will allow him to compete for a record eighth world championship.

Despite only qualifying seventh, Lewis Hamilton was positive with the progress Mercedes have made so far in Bahrain and he's optimistic they can close the gap on the frontrunners.

And 24 hours later, team principal Wolff remarkably conceded that the Silver Arrows, the constructor which once dominated the sport, will have to abandon their controversial zero-sidepod concept in order to challenge again.

"We are absolutely in the same choir," Wolff told Sky Sports F1.

He added to the written media: "I don't think that this package is going to be competitive eventually.

"We gave it our best go over the winter and now we all just need to regroup, sit down with the engineers, be totally non-dogmatic and ask what is the development direction we want to pursue in order to be able to win races.

"We hit our targets. That's why I say we gave it our best shot. But the moment comes when the stopwatch comes out and that showed us that we are not good enough.

"At this team we blame the problem not the person. I have responsibilities. I need to fire myself if I want to do something."

https://www.skysports.com/f1/news/12472/12825186/mercedes-to-...

Av Sidde
Skrivet av heatm:

Såg nu att Mercedes fimpar zero pod-konceptet. En YouTubevideo som källa så är inte 100% säker men någon annan orkar säkert hitta en riktig artikel.
Mercedes fimpar alltså utvecklingsspåret de har fokuserat på i över ett år så deras säsong lär bli miserabel och Aston Martin har en bra chans att komma tvåa i mästerskapet och en stor chans att komma trea. 🤯

Sen var det som jag tänkte mig, en "control unit", alltså en ECU som failade på Ferrari verkade det som. Tydligen bytte de ut den första innan loppet för de såg några knepigheter, och den nya failade. Man får ha två per säsong så Leclerc lär behöva ta straff redan.

Italienare och elektronik ni vet... 🤌🤪😂

Vilken start på detta F1-år.

Finner det väldigt märkligt hur Merc kommunicerar detta.
Under tiden försäsongstesterna pågick säger de att allt är bra och att de är på rätt spår och kommer nya uppdateringar på pågående riktning. Sedan plötsligt bara så är allt åt helvete och de måste bara bygga om.

Jag ser följande två tänkbara scenarion:
Antingen är det bara kommunikation externt för att slippa lite press och frågor och sedan hoppas man på uppdateringarna kommer fungera. För vad kan de har lärt sig under racehelgen som de inte lärde sig under testerna eller förövrigt under hela vintern?

Eller så är det kommunikation riktat internt där det är kanske är en intern kamp om vilket koncept som ska gälla och att någon nu satt ned foten och nu är det dags att släppa det konceptet de valt och satsa på det alternativ som uppenbart inte fick gå till produktion.

Av Sidde
Skrivet av zyberzero:

O boy, do I have news for you! De släppte nyheten om luren nyss; Tyvärr ganska stor skärm, men bara "Hörlursuttag: 3.5 mm" är ju en vinst - och både utbytbart batteri och skärm. Kanske inte allt du bad om, men ett steg i rätt riktning.

https://www.nokia.com/phones/sv_se/nokia-g-22

Operativsystem:Android™ 12
OS-uppgraderingar:2 years of OS upgrades

Bra marknadsfört att hålla i längden.
Men varför då 2år…

Av Sidde
Skrivet av Snubb1:

Jolla JP-1301 tillverkades inte i Finland men den utvecklades där.

Mistänkte det.
Men tillverkares N950 och N9 i Finland?
Och hur stor procent? Eller är de bara monterade? Jag har dålig koll på hur mycket Nokia gjorde själva men när telefoner innehåller merparten kretsat från Asien är det ju få som kan vara tillverkade utanför Asien också. Touchscreen, batteri, cpu, ram, lagring. Det tillsammans måste ju vara nästan hela telefonen.

Schweiziska klockar har väl krav på 60% av komponenterna måste vara skapat i Schweiz för att få bära ordet Swiss Made

Av Sidde
Skrivet av Wyver:

Nokia N9 måste vara den sista Nokia mobilen jag har ägt som var Made in Finlands. Ganska troligt det var sista Nokia mobilen som tillverkades i Finland också.

Eftersom du nämner just N9 så kan jag tycka att vi borde kunna nämna Jolla också i fotnoten som sista mobilen. Även om teamet? bakom N9 gjorde det under ett annat företagsnamn.

Av Sidde

MS Flight Sim äter både RAM och VRAM, kräver många trådar men blir samtidigt snabbt trottlad av main thread inte hinner med.
Det äter också 150-200GB disutrymme och växer för varje update. RAM-användningen har minskat lite på senare tid faktiskt men jag har inte haft några problem att fylla 64GB RAM i spelet under en period.

I princip är det nog en av de mest krävande spelen på marknaden om man tittar på hela paketet och inte på enskild komponent.

Av Sidde
Skrivet av wuseman:

Vem vågar vara öppen och ärlig med detta, får man verkligen öppna och kolla i Apple datorer om man har inte har blivit en av reperatörerna som fått godkänt för det? Det kanske finns någon här iofs.

Finns iaf möjlighet att som privatperson reparera själv.

https://support.apple.com/self-service-repair
"Self Service Repair is intended for individuals with the knowledge and experience to repair electronic devices. If you are experienced with the complexities of repairing electronic devices, Self Service Repair provides you with access to genuine Apple parts, tools, and repair manuals to perform your own out-of-warranty repair. Follow these steps to perform a variety of out-of-warranty repairs for iPhone and Mac, such as display replacements."

Apple tillhandahåller också reparationsdokumentation, tex:
https://manuals.info.apple.com/MANUALS/2000/MA2118/en_US/mac-...

Av Sidde
Skrivet av jnsson:

Minnesmoduler? Du menar RAM-minne? I så fall är inte det SSD/HDD som jag pratade om

SSD-kontrollern sitter inte på minnet utan i CPUn. Så därför är det inte tekniskt sett SSD-minnen man monterar i slottarna. Men de är fortfarande slottade lagringsminnen av samma typ som sitter i SSD-diskar.

https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fcdn....

Av Sidde
Skrivet av jnsson:

Alla Apple M chipp har fastlödd SSD och även de sista Intel CPU:erna har fastlödd SSD om jag minns rätt

Mac Studio har 2st slottar där diskarna sitter i.
Dock är det rena minnesmoduler och inte SSD-diskar.

Av Sidde
Skrivet av dlq84:

Det är inte ett deviceid heller. Sluta flytta målstolparna.

Mig veterligen kunde man boota osx (tiger) på en pentium4 i princip från dag1 när apple bytte från PPC.
Och Apple har aldrig försökt stoppa folk från att köra osx även utan att köpa det på x86.
Däremot har de aktivt försökt stoppa företag att sälja x86-hw som bundlas med osx.

Apple har till och med bundlat osx/macos med drivrutiner till hw som de aldrig öht sålt.
Och de tog bort serienummer innan x86-bytet.
Dessutom erbjuder de alla ISOs på deras webbplats.

Så jag har iaf svårt att se att Apple försöker förhindra folk från att köra macos på datorer som inte är sålda av Apple. Däremot försöker de förhindra att folk ska sälja datorer med MacOS på.

Av Sidde
Skrivet av dlq84:

Det är en hemlig sträng a.k.a nyckel som behövs för att boota. Jag sade aldrig "serienyckel" eller "licensnyckel", bara "nyckel".

Vad definieras som hemlig här? Är alla device idn hemliga bara för att det inte står på kartongen?
Nu jobbar jag visserligen med hemliga material på jobbet så jag tror vi har olika definitioner av hemligt.

Av Sidde

Tror inte du förstår vad det där innebär. Det är inte en nyckel för OSet. Det är en variabel satt av HW. Inte nödvändigtvis den enda heller utan bara något som uppenbart fungerar. Men det är inte en licensnyckel, vilket var det jag svarade.

Av Sidde
Skrivet av filbunke:

Gällande artikelämnet så tillåter inte apple att man kör det naitve.

Hur menar du nu? Apple tillåter andra OS att bootas på alla M1 och M2-macar.
Det är till och med en meny-inställning man gör där man direkt tillåter ej signerad mjukvara att boota.

Av Sidde
Skrivet av GuessWho:

Det blir svårare när "hårddisken" är fastlödd(a) chip på moderkortet (SSD).
Dessutom har Apple någon form av kryptering för deras SSDer som gör det ännu mer komplicerat att byta.

Apple har satt SSD-kontrollern i "CPUn". Därför fungerar inte lagringen som vanliga diskar.
Och i t.ex Mac Studion som jag har är inte disken fastlödd.

Av Sidde
Skrivet av DasIch:

Det finns en krypteringsnyckel för vissa filer/drivrutiner (jag har inte fått riktig klarhet i exakt vad den låser upp): "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc".

Googlar jag på det handlar det om SMC. Alltså power management. Det är så uppenbart inte licensnyckel iaf. Min gissning snarare en variabel för att validera att det är en HW från Apple och och de behövde ett sätta något värde, så de skrev ett meddelande.

Av Sidde
Skrivet av dlq84:

Jodå, det finns inget olagligt med att ladda ner image direkt från Apples servrar och använda nyckeln som läckte via domstolen i USA. Som OSX-KVM gör. Bryter mot licenser är en annan sak.

Nyckel?
Är ju inge serienyckel/licensnyckel i MacOS sedan typ 20år. Däremot finns det hårdvaruserienummer men det är ju inte kopplat till mjukvarans licens utan för att berätta vilken HW det är.

Av Sidde
Skrivet av sAAb:

Det ser ju bra ut! Men du hade ingen länk så man kunde inte jämföra.

Här fanns länk, så här kommer första jämförelsen per deltest.

https://browser.geekbench.com/v6/cpu/compare/16040?baseline=1...

Jahapp, det var rejäla förluster överallt för mig.

Men, den är ju fem år gammal...

Glömde visst länken
https://browser.geekbench.com/v6/cpu/578

Av Sidde

Bra eller dåligt måste väl bero på vad du förväntar dig.
Ser att en lika dan dator till min fanns:

CPU Information
Name Apple M1 Max
Topology 1 Processor, 10 Cores
Identifier Apple M1 Max
Base Frequency 3.22 GHz

Memory Information
Size 32.00 GB

Av Sidde
Skrivet av Yoshman:

Däremot väldigt svårt att se något större värde att inom samma system som hanteras av en och samma organisation ta overhead för varje "microservice" ska köra i en egen VM (blir löjligt overhead). Om man inte tar det för varje microservice, är det bara

Är väl kanske en definitionsfråga vad ett system är och när det blir ett till system.
Men ta frontend av en applikation vs backend. Eller webbcache framför en applikation.

I dessa scenarion är det rätt smidigt att se till att undvika att dela på samma io/resurser och framförallt om man blandar in nätverksstacken som kommer med flera container-plattformar där man måste trycka trafiken genom samma proxys. Då kan det vara rimligt att separera dessa på helt olika VMar/interface etc. men såklart också annat kan särskiljas. När man lägger allt i samma VM men i olika containrar är det många rätt svårdefinierade resursdelningar man gör och det kan vara rätt komplext att reda ut och sätta bra gränsvärden för alla dessa resurser. Allt från hur många DNS-slagningar får gå från respektive container till hur hög IO mot disken får man ha.

Eller i en fråga om olika känslighet på datat. Du har en inloggad del av en applikation kontra en publik del.
Då kanske kan vill säkerställa att även om någon confat fel, inte patchat eller annan orsak så riskerar man inte att det känsliga datat görs åtkomlig via fel väg. Hängslen och livrem samtidigt.

Ibland är det helt enkelt mer rimligt att ta overhead up front för att man kan se till att skydda eller dedikera resurser.
Allt handlar ju inte om att vara resurseffektiv eller billig.

Av Sidde
Skrivet av Yoshman:

Det är därför hypervisors inte är poänglösa. De har högre kostnad, men de isolerar även OS-kärnor.
Är därför vettigt att använda hypervisors för att partionera olika organisationer som delar HW. Olika organisationer har i normalfallet ingen anledning att lita på varandra.

Men i grunden gäller ändå: kan du inte lita på OS-kärnan är du ändå rökt. Graden av "rökt" spelar liksom inte så stor roll...

Containers har lägre, i vissa fall väsentligt lägre, overhead för kommunikation + de kostar klart mindre resurser att köra (i nivå med vilken process som helst, det är inte alls sant för hypervisors då de drar runt ett extra OS). Inom samma projekt/organisation finns därför flera anledningar att välja en sådan lösning där.

Normal kommer man inte åt någon HW direkt från en container. Det är möjligt att tillåta det och i det läget har det som kör inuti container samma direkta access till HW som "host". Men är typiskt också möjligt att ge indirekt access till HW via "virtuell" HW som delas mellan host/container och hosten agerar proxy mot verklig HW.

Grafikkort eller andra former av machine-learning-hw är väl kanske det vanligaste idag för detta med att dela HW mellan containrar där man kan få informationsläckage eller i värre fall container escape med priv esc-sårbarheter mellan containrar.

Skrivet av Yoshman:

Fast just filsystemet är något man i väldigt nära 100 % inte direkt delar mellan containers och "host", varför skulle man göra det? Undantaget är "bind-mounts", men det är väl mer ett utvecklingshjälpmedel än något man använder i drift?

/proc och /sys går numera att till största del "emulera", d.v.s. det man ser i en container är inte direktaccess till host:ens /proc och /sys.

Det finns tyvärr många scenarion där filsystem delas och precis som du säger är det det ofta med monteringar av t.ex nätverksfilsystem. Men det finns också andra sammanhang där man jobbar med så stora filer att det görs av kanske ren praktisk begränsning. Det jag ville säga var mer att det görs och det är ett problem i sig
Containrar möjliggör att man kan göra "fullösningar" och där man kan göra något kommer det ske.

Och påtal om /proc.
https://access.redhat.com/security/vulnerabilities/runcescape
https://www.trendmicro.com/vinfo/us/security/news/vulnerabili...

Skrivet av Yoshman:

Finns en rad olika sätt att dela nätverk. Standardvalet är nästa alltid Dockers "bridge" mode som ger "containers" access till t.ex. internet via host:ens nätverk. Men det går fortfarande via virtuella Ethernet enheter, "containers" har inte direkt access till de fysiska interfacen.

Det är möjligt att ge direkt access till "containers", men varför skulle man göra det när det på en modern dator går att pusha åtskilliga TB/s över "veth"?

Portar man exponerar mot containers blir i "bridge" mode ofta även synliga utåt. Fast det beror på firewall/iptables policy och är fullt möjligt att ha en default-policy satt till "block" för all forwarding av trafik in mot containers. I det läget måste man explicit öppna varje port/service utåt, men går att ha en konfig som gör dem åtkomliga lokalt från host (eller så blockar man även det by default).

Vidare går det att låta specifika containers ha en separat nätverkslösning, t.ex. ett virtuellt Ethernet som inte är tillagd till host-bryggan. I det läget får man hantera hosten som vilken router som helst när det kommer till att bestämma vilken trafik som ska nå det virtuella Ethernet:et.

Det går absolut att ställa till det för sig här, men lösningarna finns!

Precis som du säger. Det "går" att ställa till det för sig. Och jag kan säga att det gör det.
I många containerlösningar är det också så att host-os:et erbjuder x antal funktioner by default. Som t.ex DNS.
När man gör sådant skapar man också sårbarheter kopplat till dessa tjänster där applikationer kan komma åt host-os:et på t.ex ett lokalt interface. Men när man öppnar ett lokalt interface öppnar man också upp sig för andra brister som att t.ex man då måste ha koll på vad som bindar till det lokala interfacet.

Och det går också att blockera en hel del här men samtidigt så skeppas många leverantörer sina container-klusterlösningar eller sina applikationer med direkt dålig config by default.

Summeringen är väl att det går att göra rätt bra lösningar om man vet bristerna och problem.
Men många gör fel, så är det ett jobb i uppförsbacke.
I många av dessa usecases hade det dock by default varit klart säkrare med vanliga VMar.

(Än värre är det mer dessa kluster-apier dock som i t.ex openshift, k8s eller hos molnleverantörerna.
Där varje container får automatiskt api-nyckel för att prata in mot en central tjänst som i sin tur har access till flera andra containrar. Det är organisationer där ute fått hela sin organisation kapad genom sådant tyvärr.
Detta är dock kanske inte containrarnas isolering som är felet)

Skrivet av Yoshman:

Antar att du pratar om host-filsystemet ovan. Varför skulle en container överhuvudtaget ha någon access till det i normalfallet? Att tillåta det låter verkligen som en disaster waiting to happen...

Normalfallet är väl ändå att varje container har sitt helt privata filsystem + möjligen någon delad volym + eventuellt bind-mounts (och dessa ger access till host-filsystemet).

Och om man nu måste ge sådan access: om Docker services inte kör som root har containers ingen root-access till host-filsystemet med mindre än att det finns kernel-buggar.

Både host-filsystemet där man ibland delar access.
Jag kan inte ge argument till varför man gör så med hostfilsystemet.
Men jag kan garantera att det görs och det är gott om företag som levererar sina produkter på det viset.

Men det är även problem i privata filsystemet innuti containrar där t.ex webbservrar eller annat startar sin tjänst som "root". Och att den processen då har rättigheter att ändra sin egen konfiguration i sin runtime etc. Det är bara dålig hygien men återigen där så skeppas många container-configs på det viset redan från start.