Den frie kafeen

[rockPaperScissors()]

Ekte menn jobber i CMD.EXE.

[tomsi42]

Ekte menn jobber i CMD.EXE.

Ekte menn bruker ikke Mickeysoft produkter

[rockPaperScissors()]

 

Ekte menn jobber i CMD.EXE.

Ekte menn bruker ikke Mickeysoft produkter

 

..CMD.EXE i OS/2 Warp.

[tomsi42]

..CMD.EXE i OS/2 Warp.

 

Du er unnskyld; men bare så vidt

[Omnithunder]

 

..CMD.EXE i OS/2 Warp.

 

Du er unnskyld; men bare så vidt

 

Ekte menn tilpasser seg... ektemenn går i tøffler :-)

[RattleBattle]

..CMD.EXE i OS/2 Warp.

If it looks like a duck...osv.

[rockPaperScissors()]

Smertefullt uansett.

 

..

 

Jeg skal ha ny jobb-bærbar i løpet av våren, men jeg er veldig i tvil om å konfigurere den med høyeste skjermoppløsning ettersom min erfaring er at hi-dpi fungerer dårlig med ekstern lo-dpi skjerm. +at jeg ikke ønsker overraskelser med programmer som ikke fungerer optimalt med hi-dpi. Ville dere gått hi-dpi i dag, eller ventet noen år?

 

Vil Wayland gi oss bedre brukeropplevelse med skjermer med liten og stor oppløsning?

[stigfjel]

Ekte menn bruker ikke Mickeysoft produkter

Wintendo...

[Occi]

Så mye krangling det skulle være om terminaler da. Ser ikke helt poenget, da det har lite å si så lenge dere ikke bruker riktig editor engang (vim) :-)

[AM2petterk]

Smertefullt uansett.

 

..

 

Jeg skal ha ny jobb-bærbar i løpet av våren, men jeg er veldig i tvil om å konfigurere den med høyeste skjermoppløsning ettersom min erfaring er at hi-dpi fungerer dårlig med ekstern lo-dpi skjerm. +at jeg ikke ønsker overraskelser med programmer som ikke fungerer optimalt med hi-dpi. Ville dere gått hi-dpi i dag, eller ventet noen år?

 

Vil Wayland gi oss bedre brukeropplevelse med skjermer med liten og stor oppløsning?

Hadde en Asus Zenbook U500VZ med 2880x1620 15" skjerm, og det fungerte iallefall bra med Cinnamon så lenge du justerte "Scaling" og valgte "HiDPI" i "General settings". Nå brukte jeg riktignok ikke den så mye med en ekstern skjerm, men de få gangene jeg brukte den med en 55" Full HD tv fungerte det iallefall fint å surfe osv.

[Lycantrophe]

Ser antydninger her om at Cinnamon på noen måte er relevant.

 

ok.

[rockPaperScissors()]

 

Smertefullt uansett.

 

..

 

Jeg skal ha ny jobb-bærbar i løpet av våren, men jeg er veldig i tvil om å konfigurere den med høyeste skjermoppløsning ettersom min erfaring er at hi-dpi fungerer dårlig med ekstern lo-dpi skjerm. +at jeg ikke ønsker overraskelser med programmer som ikke fungerer optimalt med hi-dpi. Ville dere gått hi-dpi i dag, eller ventet noen år?

 

Vil Wayland gi oss bedre brukeropplevelse med skjermer med liten og stor oppløsning?

Hadde en Asus Zenbook U500VZ med 2880x1620 15" skjerm, og det fungerte iallefall bra med Cinnamon så lenge du justerte "Scaling" og valgte "HiDPI" i "General settings". Nå brukte jeg riktignok ikke den så mye med en ekstern skjerm, men de få gangene jeg brukte den med en 55" Full HD tv fungerte det iallefall fint å surfe osv.

 

Så lenge jeg kan plugge i projektor eller desktop-skjerm uten at alt er oppskalert på den eksterne enheten, eller at alt i motsatt fall er uleselig smått på den interne skjermen, så hadde det vært en god start i alle fall.

[TI-83]

OpenBox er kjappere

Ikke å konfigurere.

[Occi]

Openbox' XML config kan brenne, men obmenu osv. gjør det litt bedre.

[rockPaperScissors()]

RH måtte oppdatere denne Squid buggen og kommentere at det var for en ikke-utgitt versjon av RHEL etter at saken spredte seg på sosiale medier.

https://bugzilla.redhat.com/show_bug.cgi?id=1202858

 

Uansett hva RHEL sier, det er en type feil man ikke akkurat forventer i RHEL produkter, eller at den blir liggende åpen lenge.

Endret 24. mars 2015 av rockPaperScissors()

[kpolberg]

er ikke helt sikker på om jeg er enig med deg. Jeg hadde ikke forventet å få det i prod nei. Men i pakker som enda ikke er frigitt til prod, så ser jeg ingen problem med bugs, uansett hvor graverende de skulle være.

[rockPaperScissors()]

er ikke helt sikker på om jeg er enig med deg. Jeg hadde ikke forventet å få det i prod nei. Men i pakker som enda ikke er frigitt til prod, så ser jeg ingen problem med bugs, uansett hvor graverende de skulle være.

Tviler ikke at RH har kontroll, men jeg antar Debian Sid og Arch brukere ikke ville godtatt at slike feil blir liggende åpne. Det er en ganske grov feil idet brukere mister data.

Endret 24. mars 2015 av rockPaperScissors()

[kpolberg]

Sid og Arch blir vel ikke helt det samme? Det kan vel nesten heller sammenliknes med Fedora? Jeg hadde ikke godtatt denne type feil i Fedora heller...

[TI-83]

Openbox' XML config kan brenne, men obmenu osv. gjør det litt bedre.

 

Er veldig mange valgmuligheter der, men syns XFCE gjør jobben jeg da...

[stigfjel]

Tviler ikke at RH har kontroll, men jeg antar Debian Sid og Arch brukere ikke ville godtatt at slike feil blir liggende åpne. Det er en ganske grov feil idet brukere mister data.

Dette ser ikke jeg på som et reelt problem. Man bruker ikke beta-releaser i virksomhetskritiske produksjons- og stagemiljøer. For produksjonsreleaser har Red Hat som regel hatt stålkontroll. De er raske til å komme med viktige patcher hvis det blir avdekket alvorlige feil eller sikkerhetshull. RHEL 6.7 er fortsatt i beta, det er 6.6 som er gjeldende versjon av RHEL 6. Ville du brukt Debian Sid som OS til viktige produksjonsoppgaver? Etter mitt syn egner RHEL/CentOS seg langt bedre til serverdrift enn eks. Debian. Og ja, jeg har flere års erfaring innen dette feltet.