Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Kan man identifiera hur man är uppkopplad, tråd eller wifi?

Tråden skapades och har fått 21 svar. Det senaste inlägget skrevs .
1
  • Medlem
  • 2011-12-08 16:49

Jag skulle vilja kunna ta reda på om en användare är uppkoplad med tråd eller wifi med ett skript. Går det?

Allt går, men jag vet inte på rak arm hur man gör det, men innan man börjar rota kan det nog vara bra att precisera vad du menar:

Det fungerar nämligen inte så att en användare kan vara uppkopplad med antingen tråd eller wifi, utan de kan vara uppkopplad via båda, och olika trafik kan gå på olika nätverksinterfaces.

Därför kanske du behöver tänka på huruvida det är vilka nätverkskort som är aktiva, vilka som har en given ipadress, vilken som har trafik mot en viss server etc.

Så, precisera vad det är du EGENTLIGEN vill göra

Eftersom jag är alldeles för snäll så ska du få en kodrad som jag skulle tro kan hjälpa dig

[code]
set theIP to do shell script "netstat -i |grep '[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}' | awk '{ print $1\"\\t\"$4}'"
[\code]

Det listar de nätverksinterface som har en tilldelad ip-adress,

  • Medlem
  • 2011-12-08 21:30

Vad jag egentligen är ute efter är bandbredden. Jag kopierar ut filer vid start av InDesign, och vill veta om mottagaren har bra kräm i pipan.

Det enda tillförlitliga sättet att veta det är att mäta, typ som bredbandskollen är, men det är inte helt trivialt och bidrar ju dessutom med en fördröjning för själva mätningen.

Finns det inte någon möjlighet att ha "lazy loading", bakgrundsladdning etc?

  • Medlem
  • 2011-12-08 22:15

Lazy loading kan jag inget om, och det kanske komplicerar saken om det ska ske i startsktipt för InDesign.
Att mäta bandbredden låter för besvärligt, så jag tänkte att om man sitter på tråd i vissa ip-serier så har man bra fart.
När jag formulerar det nu så ser jag att jag nog redan har ett tillräckligt bra svar. Har man en ip-adress inom vissa serier har är man uppkopplad med tråd.

  • Medlem
  • 2011-12-08 22:15

Tack förresten.

  • Medlem
  • Uppsala
  • 2011-12-08 22:16

Jag tänker enkelt här. Borde du inte kunna sätta igång en timer, ladda hem (eller upp) en fil på ca 1 mb och direkt därefter mäta hur lång tid det tog. Därefter kan ditt skript ta ställning hur du vill göra. En trådad uppkoppling kan ju vara långsam (ADSL) och en trådlös uppkoppling kan vara snabb. Ping (dvs. latens) svarar inte alltid på om överföringshastigheten är snabb eller inte.

https://discussions.apple.com/thread/1452549?start=0&tstart=0

Det jag inte förstår är vilka beslut du ska fatta på grundval av den erhållna informationen: Om det går långsamt, vilka resurser är det du då inte kommer att ladda?

  • Medlem
  • 2011-12-08 22:34

Vi är en koncern med InDesignanvändare på sex olika geografiska platser.
När man startar InDesign körs några startskript som kopierar ut olika filer från Segevång i utkanten av Malmö dels inne i huset och dels till Malmö city, Lund, Kristianstad, Trelleborg och Ystad. Flera är så små att det inte spelar någon roll vilken bandbredd man har. Men ett paket väger runt 400 MB.
Inne i huset på Segevång märks det knappt att man kopierar 400 MB, men i de andra städerna tar det ett par minuter att starta InDesign.
Jag vill ha samma startskript i alla maskiner för minimal variation i vad som installeras.
Sitter man inne i huset har man som sagt inga problem med filkopieringen, men ute i provinserna vill man kunna ta ställning till om man vill ladda hem all data, eller helt enkelt slippa den för att InD ska starta snabbare.
Jag vet vilka IP-serier som används på respektive ort så jag kan styra vem som ska få vad genom att låta "fel" ip-nummer avbryta skriptet.

  • Avstängd
  • 2011-12-08 22:47
Ursprungligen av Baron:

...i de andra städerna tar det ett par minuter att starta InDesign...

Ursäkta att jag ler lite här

  • Medlem
  • 2011-12-08 22:52

Visst. Om du säger varför du ler.

  • Avstängd
  • 2011-12-08 22:59
Ursprungligen av Baron:

Visst. Om du säger varför du ler.

När jag börja läsa din tråd trodde jag det rörde sig om en kvart eller längre

  • Medlem
  • 2011-12-08 23:23

Le du. De där minuterna kostar oss tusentals kronor om de kommer vid fel tillfälle.

  • Avstängd
  • 2011-12-09 00:04
Ursprungligen av Baron:

Le du. De där minuterna kostar oss tusentals kronor om de kommer vid fel tillfälle.

Lite sjukt att det "går åt" en mindre förmögenhet bara för att man behöver slå en drill på arbetstid vilket tar ung. ett par minuter

Bäst vi sluter nu med detta OT sidospår innan det retar någon

  • Medlem
  • 2011-12-09 07:09

Nej nej, det är inget sånt. Vi gör morgontidningar. Om man måste atarta om ind precis före tryckstart kan det i värsya fall bli förseningsavgifter till tryckeriet. För att inte tala om den stress man upplever då dags på dygnet när saker krånglar eller tar tid.

  • Avstängd
  • 2011-12-09 09:40
Ursprungligen av Baron:

Nej nej, det är inget sånt. Vi gör morgontidningar. Om man måste atarta om ind precis före tryckstart kan det i värsya fall bli förseningsavgifter till tryckeriet. För att inte tala om den stress man upplever då dags på dygnet när saker krånglar eller tar tid.

Ah, ok då förstår jag...

Att avgöra platsen är självklart viktigt, men jag tror att det finns betydligt mer att göra än detta.

Till att börja med skulle jag gå igenom resurserna och optimera dem. Jag är säker på att du kan trimma dem väsentligt. Likaså skulle jag vara lite systematisk i att titta på olika kompressionsmetoder etc. – det skiljer mer än man tror nämligen.

Därefter skulle jag gruppera dem utifrån vilka som har "dependencies", dvs. om de förutsätter andra saker.

Efter detta skulle jag prioritera varje grupp, utifrån hur sannolikt det är att de behövs tidigt. T.ex. tror jag inte någon kommer att använda biblioteken de första minuterna efter start.

Sen måste du börja fundera på bakgrundsladdning, och därmed "asynkron" hantering. I dagsläget (utgår jag från) att ditt script är helt synkront, dvs. att du måste invänta att varje steg blir klart innan du kan fortsätta med nästa. Men med en asynkron hantering drar du bara igång bakgrundsprocesserna och så får de bli färdiga när de blir det. (går såklart också att fånga med olika metoder).

Sen är det självfallet så att den mest effektiva hanteringen är sådan som aldrig behöver ske: Har du t.ex. en server som med en effektiv metod kan tala om vad som är i behov av uppdatering med en enkel fråga, så behöver scripten bara ladda det som verkligen har ändrats.

Finns ju konsulter du kan prata vidare med också

  • Medlem
  • 2011-12-09 09:30

Så här har jag resonerat hittills:

Ursprungligen av Richard Rönnbäck:

Att avgöra platsen är självklart viktigt, men jag tror att det finns betydligt mer att göra än detta.

Till att börja med skulle jag gå igenom resurserna och optimera dem. Jag är säker på att du kan trimma dem väsentligt. Likaså skulle jag vara lite systematisk i att titta på olika kompressionsmetoder etc. – det skiljer mer än man tror nämligen.

Jag vill för en så enkel hantering av källfilerna som möjligt inte komprimera alls. En fil på en filyta ligger i en mappstruktur som speglar klientens. Lägger man en fil på ett ställe på filservern hamnar den på samma ställe lokalt.

Ursprungligen av Richard Rönnbäck:

Därefter skulle jag gruppera dem utifrån vilka som har "dependencies", dvs. om de förutsätter andra saker.

Det enda beroende de olika startskripten har är om InDesign ska var avstängt eller inte, typ om man ska byta ut sin InDesign Defaullts.

Ursprungligen av Richard Rönnbäck:

Efter detta skulle jag prioritera varje grupp, utifrån hur sannolikt det är att de behövs tidigt. T.ex. tror jag inte någon kommer att använda biblioteken de första minuterna efter start.

Jag vill ha en hantering så enkel att förstå som möjligt, typ "Om jag startar om InD så får jag ditt och datt uppdaterat." Dessutom kan faktiskt biblioteken vara något man vill ha direkt, tex om uppdateringen görs iom omstart pga en krasch.

Ursprungligen av Richard Rönnbäck:

Sen måste du börja fundera på bakgrundsladdning, och därmed "asynkron" hantering. I dagsläget (utgår jag från) att ditt script är helt synkront, dvs. att du måste invänta att varje steg blir klart innan du kan fortsätta med nästa. Men med en asynkron hantering drar du bara igång bakgrundsprocesserna och så får de bli färdiga när de blir det. (går såklart också att fånga med olika metoder).

Ursprungligen av Richard Rönnbäck:

Sen är det självfallet så att den mest effektiva hanteringen är sådan som aldrig behöver ske: Har du t.ex. en server som med en effektiv metod kan tala om vad som är i behov av uppdatering med en enkel fråga, så behöver scripten bara ladda det som verkligen har ändrats.

Nu görs uppdateringen med "rsync -r -t --delete /server/path/to/my/dir/ /local/path/to/my/dir/" vilket jag hoppas är ett någorlunda intelligent sätt att göra det på. Men bara själva kontrollen tycks ta väldigt lång tid även om inget ska uppdateras.
Jag funderar på att börja använda "stat" i stället

Ursprungligen av Richard Rönnbäck:

Finns ju konsulter du kan prata vidare med också

Jag har inget emot konsulter personligen men dels så vill jag ha en så okomplicerad lösning som möjligt, och dels så vill andra att det helst inte ska kosta pengar.
Men vi är inte alls framme här än, så om du ser en möjlighet för oss du tycker vi borde köpa så lyssnar jag och KK.

En enkel lösning som fungerar dåligt, är i själva verket en dålig lösning, inte sant?

rsync är ju känt för att vara tämligen effektiv, men något problem har du ju, eftersom det tar sån tid.

Ett sånt är säkert att du kopierar många små filer istället för en/några stora. Det är bizarrt stor skillnad i hastigheten att t.ex. överföra 1GB monolitisk fil, eller 500x2MB

Kanske kan du åtminstone dela upp det i två rsync-strukturer, en som är högprioriterad, och som du kör synkront (så att skripten väntar in dem, och ett annat som körs asynkront, Naturligtvis måste du då ta höjd för att somliga av dessa filer kanske inte hunnit uppgraderas då någon försöker använda dem, och kontrollera det på annat sätt, men normalt sett kommer det aldrig vara ett problem.

Ett annat problem jag kan se är att du sparar properties i skripten, som därmed ändras hela tiden, vilket gör att rsync inte kan matcha, utan måste överföra nya filer.

  • Medlem
  • 2011-12-09 16:26

Jag försöker få enkla lösningar att fungera, inte att inte fungera.

Skripten är inga problem, det är InD-biblioteken som är stora. Där kan jag tänka mig att börja komprimera, det är ju ofantliga mängder luft i dem.

Jag skulle klocka zip --filesync och jämföra mot din rsync.

1
Bevaka tråden